Table Of Contents Vulnerabilities By Host
lab-preventaScan Information
Host Information
Results Summary
Results Details/
14272 - Netstat Portscanner (SSH) |
[-/+] |
19506 - Nessus Scan Information |
[-/+] |
Assets Summary (Executive)lab-preventaSummary
Details
Audits FAILED1.1.1.1 Ensure mounting of cramfs filesystems is disabled - modprobeInfoThe cramfs filesystem type is a compressed read-only Linux filesystem embedded in small footprint systems. A cramfs image can be used without having to first decompress the image.Rationale: Removing support for unneeded filesystem types reduces the local attack surface of the server. If this filesystem type is not needed, disable it. SolutionEdit or create a file in the /etc/modprobe.d/ directory ending in .conf Example: vim /etc/modprobe.d/cramfs.conf and add the following line:install cramfs /bin/true Run the following command to unload the cramfs module: # rmmod cramfs See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/modprobe -n -v cramfs | /usr/bin/awk '{print} END {if (NR == 0) print "fail"}'' returned :
insmod /lib/modules/3.10.0-1160.95.1.el7.x86_64/kernel/fs/cramfs/cramfs.ko.xz lab-preventaThe command '/usr/sbin/modprobe -n -v cramfs | /usr/bin/awk '{print} END {if (NR == 0) print "fail"}'' returned :
insmod /lib/modules/3.10.0-1160.95.1.el7.x86_64/kernel/fs/cramfs/cramfs.ko.xz 1.1.1.3 Ensure mounting of udf filesystems is disabled - modprobeInfoThe udf filesystem type is the universal disk format used to implement ISO/IEC 13346 and ECMA-167 specifications. This is an open vendor filesystem type for data storage on a broad range of media. This filesystem type is necessary to support writing DVDs and newer optical disc formats.Rationale: Removing support for unneeded filesystem types reduces the local attack surface of the system. If this filesystem type is not needed, disable it. SolutionEdit or create a file in the /etc/modprobe.d/ directory ending in .conf Example: vi /etc/modprobe.d/udf.conf and add the following line:install udf /bin/true Run the following command to unload the udf module: # rmmod udf See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/sbin/modprobe -n -v udf | /usr/bin/awk '{print} END {if (NR == 0) print "fail"}'' returned :
insmod /lib/modules/3.10.0-1160.95.1.el7.x86_64/kernel/lib/crc-itu-t.ko.xz insmod /lib/modules/3.10.0-1160.95.1.el7.x86_64/kernel/fs/udf/udf.ko.xz lab-preventaThe command '/sbin/modprobe -n -v udf | /usr/bin/awk '{print} END {if (NR == 0) print "fail"}'' returned :
insmod /lib/modules/3.10.0-1160.95.1.el7.x86_64/kernel/lib/crc-itu-t.ko.xz insmod /lib/modules/3.10.0-1160.95.1.el7.x86_64/kernel/fs/udf/udf.ko.xz 1.1.2 Ensure /tmp is configuredInfoThe /tmp directory is a world-writable directory used for temporary storage by all users and some applications.Rationale: Making /tmp its own file system allows an administrator to set the noexec option on the mount, making /tmp useless for an attacker to install executable code. It would also prevent an attacker from establishing a hardlink to a system setuid program and wait for it to be updated. Once the program was updated, the hardlink would be broken and the attacker would have his own copy of the program. If the program happened to have a security vulnerability, the attacker could continue to exploit the known flaw. This can be accomplished by either mounting tmpfs to /tmp, or creating a separate partition for /tmp. Impact: Since the /tmp directory is intended to be world-writable, there is a risk of resource exhaustion if it is not bound to a separate partition. Running out of /tmp space is a problem regardless of what kind of filesystem lies under it, but in a default installation a disk-based /tmp will essentially have the whole disk available, as it only creates a single / partition. On the other hand, a RAM-based /tmp as with tmpfs will almost certainly be much smaller, which can lead to applications filling up the filesystem much more easily. SolutionCreate or update an entry for /tmp in either /etc/fstab OR in a systemd tmp.mount file:If /etc/fstab is used: configure /etc/fstab as appropriate. Example: tmpfs/tmptmpfs defaults,rw,nosuid,nodev,noexec,relatime 0 0 Run the following command to remount /tmp # mount -o remount,noexec,nodev,nosuid /tmp OR if systemd tmp.mount file is used: run the following command to create the file /etc/systemd/system/tmp.mount if it doesn't exist: # [ ! -f /etc/systemd/system/tmp.mount ] && cp -v /usr/lib/systemd/system/tmp.mount /etc/systemd/system/ Edit the file /etc/systemd/system/tmp.mount: [Mount] What=tmpfs Where=/tmp Type=tmpfs Options=mode=1777,strictatime,noexec,nodev,nosuid Run the following command to reload the systemd daemon: # systemctl daemon-reload Run the following command to unmask and start tmp.mount: # systemctl --now unmask tmp.mount See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/mount | /usr/bin/grep 'on /tmp '' did not return any result
lab-preventaThe command '/usr/bin/mount | /usr/bin/grep 'on /tmp '' did not return any result
1.1.24 Disable USB Storage - modprobeInfoUSB storage provides a means to transfer and store files insuring persistence and availability of the files independent of network connection status. Its popularity and utility has led to USB-based malware being a simple and common means for network infiltration and a first step to establishing a persistent threat within a networked environment.Rationale: Restricting USB access on the system will decrease the physical attack surface for a device and diminish the possible vectors to introduce malware. SolutionEdit or create a file in the /etc/modprobe.d/ directory ending in .conf Example: vim /etc/modprobe.d/usb_storage.conf Add the following line:install usb-storage /bin/true Run the following command to unload the usb-storage module: rmmod usb-storage Additional Information: An alternative solution to disabling the usb-storage module may be found in USBGuard. Use of USBGuard and construction of USB device policies should be done in alignment with site policy. See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/sbin/modprobe -n -v usb-storage | /usr/bin/awk '{print} END {if (NR == 0) print "fail"}'' returned :
insmod /lib/modules/3.10.0-1160.95.1.el7.x86_64/kernel/drivers/usb/storage/usb-storage.ko.xz 1.1.6 Ensure /dev/shm is configured - fstabInfo/dev/shm is a traditional shared memory concept. One program will create a memory portion, which other processes (if permitted) can access. Mounting tmpfs at /dev/shm is handled automatically by systemd.Rationale: Any user can upload and execute files inside the /dev/shm similar to the /tmp partition. Configuring /dev/shm allows an administrator to set the noexec option on the mount, making /dev/shm useless for an attacker to install executable code. It would also prevent an attacker from establishing a hardlink to a system setuid program and wait for it to be updated. Once the program was updated, the hardlink would be broken and the attacker would have his own copy of the program. If the program happened to have a security vulnerability, the attacker could continue to exploit the known flaw. SolutionEdit /etc/fstab and add or edit the following line:tmpfs /dev/shm tmpfs defaults,noexec,nodev,nosuid,seclabel 0 0 Run the following command to remount /dev/shm: # mount -o remount,noexec,nodev,nosuid /dev/shm Additional Information: An entry for /dev/shm in /etc/fstab will take precedence. tmpfs can be resized using the size={size} parameter in /etc/fstab. If we don't specify the size, it will be half the RAM. Resize tmpfs example: tmpfs /dev/shm tmpfs defaults,noexec,nodev,nosuid,size=2G 0 0 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/bin/egrep '\s/dev/shm\s' /etc/fstab | /bin/awk '{print} END {if (NR == 0) print "none"; else print}'' returned :
none lab-preventaThe command '/bin/egrep '\s/dev/shm\s' /etc/fstab | /bin/awk '{print} END {if (NR == 0) print "none"; else print}'' returned :
none 1.1.7 Ensure noexec option set on /dev/shm partitionInfoThe noexec mount option specifies that the filesystem cannot contain executable binaries.Rationale: Setting this option on a file system prevents users from executing programs from shared memory. This deters users from introducing potentially malicious software on the system. SolutionEdit the /etc/fstab file and add noexec to the fourth field (mounting options) for the /dev/shm partition. See the fstab(5) manual page for more information.Run the following command to remount /dev/shm: # mount -o remount,noexec,nodev,nosuid /dev/shm Additional Information: /dev/shm is mounted automatically by systemd. /dev/shm needs to be added to /etc/fstab to add mount options even though it is already being mounted on boot. See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/bin/mount | /bin/grep 'on /dev/shm '' returned :
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,seclabel) lab-preventaThe command '/bin/mount | /bin/grep 'on /dev/shm '' returned :
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,seclabel) 1.3.1 Ensure AIDE is installedInfoAIDE takes a snapshot of filesystem state including modification times, permissions, and file hashes which can then be used to compare against the current state of the filesystem to detect modifications to the system.Note: The prelinking feature can interfere with AIDE because it alters binaries to speed up their start up times. Run prelink -ua to restore the binaries to their prelinked state, thus avoiding false positives from AIDE. Rationale: By monitoring the filesystem state compromised files can be detected to prevent or limit the exposure of accidental or malicious misconfigurations or modified binaries. SolutionRun the following command to install AIDE:# yum install aide Configure AIDE as appropriate for your environment. Consult the AIDE documentation for options. Initialize AIDE: Run the following commands: # aide --init # mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe package 'aide-0.0.0-0' is not installed
lab-preventaThe package 'aide-0.0.0-0' is not installed
1.3.2 Ensure filesystem integrity is regularly checked - systemctl is-enabled aidecheck.serviceInfoPeriodic checking of the filesystem integrity is needed to detect changes to the filesystem.Rationale: Periodic file checking allows the system administrator to determine on a regular basis if critical files have been changed in an unauthorized fashion. SolutionIf cron will be used to schedule and run aide check Run the following command:# crontab -u root -e Add the following line to the crontab: 0 5 * * * /usr/sbin/aide --check OR if aidecheck.service and aidecheck.timer will be used to schedule and run aide check: Create or edit the file /etc/systemd/system/aidecheck.service and add the following lines: [Unit] Description=Aide Check [Service] Type=simple ExecStart=/usr/sbin/aide --check [Install] WantedBy=multi-user.target Create or edit the file /etc/systemd/system/aidecheck.timer and add the following lines: [Unit] Description=Aide check every day at 5AM [Timer] OnCalendar=*-*-* 05:00:00 Unit=aidecheck.service [Install] WantedBy=multi-user.target Run the following commands: # chown root:root /etc/systemd/system/aidecheck.* # chmod 0644 /etc/systemd/system/aidecheck.* # systemctl daemon-reload # systemctl enable aidecheck.service # systemctl --now enable aidecheck.timer See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command returned :
Failed to get unit file state for aidecheck.service: No such file or directory disabled lab-preventaThe command returned :
Failed to get unit file state for aidecheck.service: No such file or directory disabled 1.3.2 Ensure filesystem integrity is regularly checked - systemctl is-enabled aidecheck.timerInfoPeriodic checking of the filesystem integrity is needed to detect changes to the filesystem.Rationale: Periodic file checking allows the system administrator to determine on a regular basis if critical files have been changed in an unauthorized fashion. SolutionIf cron will be used to schedule and run aide check Run the following command:# crontab -u root -e Add the following line to the crontab: 0 5 * * * /usr/sbin/aide --check OR if aidecheck.service and aidecheck.timer will be used to schedule and run aide check: Create or edit the file /etc/systemd/system/aidecheck.service and add the following lines: [Unit] Description=Aide Check [Service] Type=simple ExecStart=/usr/sbin/aide --check [Install] WantedBy=multi-user.target Create or edit the file /etc/systemd/system/aidecheck.timer and add the following lines: [Unit] Description=Aide check every day at 5AM [Timer] OnCalendar=*-*-* 05:00:00 Unit=aidecheck.service [Install] WantedBy=multi-user.target Run the following commands: # chown root:root /etc/systemd/system/aidecheck.* # chmod 0644 /etc/systemd/system/aidecheck.* # systemctl daemon-reload # systemctl enable aidecheck.service # systemctl --now enable aidecheck.timer See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command returned :
Failed to get unit file state for aidecheck.timer: No such file or directory disabled lab-preventaThe command returned :
Failed to get unit file state for aidecheck.timer: No such file or directory disabled 1.3.2 Ensure filesystem integrity is regularly checked - systemctl status aidecheck.timerInfoPeriodic checking of the filesystem integrity is needed to detect changes to the filesystem.Rationale: Periodic file checking allows the system administrator to determine on a regular basis if critical files have been changed in an unauthorized fashion. SolutionIf cron will be used to schedule and run aide check Run the following command:# crontab -u root -e Add the following line to the crontab: 0 5 * * * /usr/sbin/aide --check OR if aidecheck.service and aidecheck.timer will be used to schedule and run aide check: Create or edit the file /etc/systemd/system/aidecheck.service and add the following lines: [Unit] Description=Aide Check [Service] Type=simple ExecStart=/usr/sbin/aide --check [Install] WantedBy=multi-user.target Create or edit the file /etc/systemd/system/aidecheck.timer and add the following lines: [Unit] Description=Aide check every day at 5AM [Timer] OnCalendar=*-*-* 05:00:00 Unit=aidecheck.service [Install] WantedBy=multi-user.target Run the following commands: # chown root:root /etc/systemd/system/aidecheck.* # chmod 0644 /etc/systemd/system/aidecheck.* # systemctl daemon-reload # systemctl enable aidecheck.service # systemctl --now enable aidecheck.timer See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command returned :
Unit aidecheck.timer could not be found. lab-preventaThe command returned :
Unit aidecheck.timer could not be found. 1.4.1 Ensure bootloader password is setInfoSetting the boot loader password will require that anyone rebooting the system must enter a password before being able to set command line boot parametersRationale: Requiring a boot password upon execution of the boot loader will prevent an unauthorized user from entering boot parameters or changing the boot partition. This prevents users from weakening security (e.g. turning off SELinux at boot time). Impact: If password protection is enabled, only the designated superuser can edit a Grub 2 menu item by pressing 'e' or access the GRUB 2 command line by pressing 'c' If GRUB 2 is set up to boot automatically to a password-protected menu entry the user has no option to back out of the password prompt to select another menu entry. Holding the SHIFT key will not display the menu in this case. The user must enter the correct username and password. If unable, the configuration files will have to be edited via the LiveCD or other means to fix the problem You can add --unrestricted to the menu entries to allow the system to boot without entering a password. Password will still be required to edit menu items. SolutionFor newer grub2 based systems (Release 7.2 and newer), create an encrypted password with grub2-setpassword :# grub2-setpassword Enter password: <password> Confirm password: <password> OR For older grub2 based systems, create an encrypted password with grub2-mkpasswd-pbkdf2: # grub2-mkpasswd-pbkdf2 Enter password: <password> Reenter password: <password> Your PBKDF2 is <encrypted-password> Add the following into /etc/grub.d/01_users or a custom /etc/grub.d configuration file: cat <<EOF set superusers='<username>' password_pbkdf2 <username> <encrypted-password> EOF Note: If placing the information in a custom file, do not include the 'cat << EOF' and 'EOF' lines as the content is automatically added from these files The superuser/user information and password should not be contained in the /etc/grub.d/00_header file. The information can be placed in any /etc/grub.d file as long as that file is incorporated into grub.cfg. It is preferable to enter this data into a custom file, such as /etc/grub.d/40_custom, so it is not overwritten should the Grub package be updated Run the following command to update the grub2 configuration: # grub2-mkconfig -o /boot/grub2/grub.cfg Additional Information: The older method will also work on Release 7.2 and newer systems This recommendation is designed around the grub2 bootloader, if LILO or another bootloader is in use in your environment enact equivalent settings. Replace /boot/grub2/grub.cfg with the appropriate grub configuration file for your environment See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaNo files found: /boot/grub2/user.cfg
lab-preventaNo files found: /boot/grub2/user.cfg
1.4.2 Ensure permissions on bootloader config are configured - grub.cfgInfoThe grub configuration file contains information on boot settings and passwords for unlocking boot options. The grub2 configuration is usually grub.cfg. On newer grub2 systems the encrypted bootloader password is contained in user.cfg.If the system uses UEFI, /boot/efi is a vfat filesystem. The vfat filesystem itself doesn't have the concept of permissions but can be mounted under Linux with whatever permissions desired. Rationale: Setting the permissions to read and write for root only prevents non-root users from seeing the boot parameters or changing them. Non-root users who read the boot parameters may be able to identify weaknesses in security upon boot and be able to exploit them. SolutionRun the following commands to set ownership and permissions on your grub configuration file(s):# chown root:root /boot/grub2/grub.cfg # test -f /boot/grub2/user.cfg && chown root:root /boot/grub2/user.cfg # chmod og-rwx /boot/grub2/grub.cfg # test -f /boot/grub2/user.cfg && chmod og-rwx /boot/grub2/user.cfg OR If the system uses UEFI, edit /etc/fstab and add the fmask=0077 option: Example: <device> /boot/efi vfat defaults,umask=0027,fmask=0077,uid=0,gid=0 0 0 Note: This may require a re-boot to enable the change Additional Information: This recommendation is designed around the grub2 bootloader. If LILO or another bootloader is in use in your environment: Enact equivalent settings Replace /boot/grub2/grub.cfg and /boot/grub2/user.cfg with the appropriate boot configuration files for your environment See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe file /boot/grub2/grub.cfg with fmode owner: root group: root mode: 0644 uid: 0 gid: 0 uneven permissions : FALSE does not match the policy value owner: root group: root mask: 077 uneven permissions : FALSE
/boot/grub2/grub.cfg lab-preventaThe file /boot/grub2/grub.cfg with fmode owner: root group: root mode: 0644 uid: 0 gid: 0 uneven permissions : FALSE does not match the policy value owner: root group: root mask: 077 uneven permissions : FALSE
/boot/grub2/grub.cfg 1.5.1 Ensure core dumps are restricted - limits.conf limits.dInfoA core dump is the memory of an executable program. It is generally used to determine why a program aborted. It can also be used to glean confidential information from a core file. The system provides the ability to set a soft limit for core dumps, but this can be overridden by the user.Rationale: Setting a hard limit on core dumps prevents users from overriding the soft variable. If core dumps are required, consider setting limits for user groups (see limits.conf(5) ). In addition, setting the fs.suid_dumpable variable to 0 will prevent setuid programs from dumping core. SolutionAdd the following line to /etc/security/limits.conf or a /etc/security/limits.d/* file:* hard core 0 Set the following parameter in /etc/sysctl.conf or a /etc/sysctl.d/* file: fs.suid_dumpable = 0 Run the following command to set the active kernel parameter: # sysctl -w fs.suid_dumpable=0 If systemd-coredump is installed: edit /etc/systemd/coredump.conf and add/modify the following lines: Storage=none ProcessSizeMax=0 Run the command: systemctl daemon-reload See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*\*[[:space:]]+hard[[:space:]]+core[[:space:]]+0[[:space:]]*$' /etc/security/limits.conf /etc/security/limits.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail lab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*\*[[:space:]]+hard[[:space:]]+core[[:space:]]+0[[:space:]]*$' /etc/security/limits.conf /etc/security/limits.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail 1.5.1 Ensure core dumps are restricted - sysctl.conf sysctl.dInfoA core dump is the memory of an executable program. It is generally used to determine why a program aborted. It can also be used to glean confidential information from a core file. The system provides the ability to set a soft limit for core dumps, but this can be overridden by the user.Rationale: Setting a hard limit on core dumps prevents users from overriding the soft variable. If core dumps are required, consider setting limits for user groups (see limits.conf(5) ). In addition, setting the fs.suid_dumpable variable to 0 will prevent setuid programs from dumping core. SolutionAdd the following line to /etc/security/limits.conf or a /etc/security/limits.d/* file:* hard core 0 Set the following parameter in /etc/sysctl.conf or a /etc/sysctl.d/* file: fs.suid_dumpable = 0 Run the following command to set the active kernel parameter: # sysctl -w fs.suid_dumpable=0 If systemd-coredump is installed: edit /etc/systemd/coredump.conf and add/modify the following lines: Storage=none ProcessSizeMax=0 Run the command: systemctl daemon-reload See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*fs\.suid_dumpable[[:space:]]*=[[:space:]]*0[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail lab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*fs\.suid_dumpable[[:space:]]*=[[:space:]]*0[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail 1.5.3 Ensure address space layout randomization (ASLR) is enabled - sysctl.conf sysctl.dInfoAddress space layout randomization (ASLR) is an exploit mitigation technique which randomly arranges the address space of key data areas of a process.Rationale: Randomly placing virtual memory regions will make it difficult to write memory page exploits as the memory placement will be consistently shifting. SolutionSet the following parameter in /etc/sysctl.conf or a /etc/sysctl.d/* file:kernel.randomize_va_space = 2 Run the following command to set the active kernel parameter: # sysctl -w kernel.randomize_va_space=2 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command returned :
fail lab-preventaThe command returned :
fail 1.6.1.6 Ensure no unconfined services existInfoUnconfined processes run in unconfined domainsNote: Occasionally certain daemons such as backup or centralized management software may require running unconfined. Any such software should be carefully analyzed and documented before such an exception is made. Rationale: For unconfined processes, SELinux policy rules are applied, but policy rules exist that allow processes running in unconfined domains almost all access. Processes running in unconfined domains fall back to using DAC rules exclusively. If an unconfined process is compromised, SELinux does not prevent an attacker from gaining access to system resources and data, but of course, DAC rules are still used. SELinux is a security enhancement on top of DAC rules - it does not replace them SolutionInvestigate any unconfined processes found during the audit action. They may need to have an existing security context assigned to them or a policy built for them.See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command returned :
00 nessus-service 21 nessusd 00 nessus-service 00 nessusd <defunct> 00 nessusd <defunct> 00 nessusd 27 nessus-agent-mo 00 sh 00 ps 00 grep 00 awk lab-preventaThe command returned :
00 nessus-service 21 nessusd 00 nessus-service 00 nessusd <defunct> 00 nessusd <defunct> 00 nessusd 25 nessus-agent-mo 00 sh 00 ps 1.7.2 Ensure local login warning banner is configured properly - banner textInfoThe contents of the /etc/issue file are displayed to users prior to login for local terminals.Unix-based systems have typically displayed information about the OS release and patch level upon logging in to the system. This information can be useful to developers who are developing software for a particular OS platform. If mingetty(8) supports the following options, they display operating system information: m - machine architecture r - operating system release s - operating system name v - operating system version - or the operating system's name Rationale: Warning messages inform users who are attempting to login to the system of their legal status regarding the system and must include the name of the organization that owns the system and any monitoring policies that are in place. Displaying OS and patch level information in login banners also has the side effect of providing detailed system information to attackers attempting to target specific exploits of a system. Authorized users can easily get this information by running the ' uname -a ' command once they have logged in. SolutionEdit the /etc/issue file with the appropriate contents according to your site policy, remove any instances of m , r , s , v or references to the OS platform# echo 'Authorized uses only. All activity may be monitored and reported.' > /etc/issue See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaFirst ERROR: \S Kernel != All activities
\S Kernel \r on an \m lab-preventaFirst ERROR: \S Kernel != All activities
\S Kernel \r on an \m 1.7.2 Ensure local login warning banner is configured properly - mrsvInfoThe contents of the /etc/issue file are displayed to users prior to login for local terminals.Unix-based systems have typically displayed information about the OS release and patch level upon logging in to the system. This information can be useful to developers who are developing software for a particular OS platform. If mingetty(8) supports the following options, they display operating system information: m - machine architecture r - operating system release s - operating system name v - operating system version - or the operating system's name Rationale: Warning messages inform users who are attempting to login to the system of their legal status regarding the system and must include the name of the organization that owns the system and any monitoring policies that are in place. Displaying OS and patch level information in login banners also has the side effect of providing detailed system information to attackers attempting to target specific exploits of a system. Authorized users can easily get this information by running the ' uname -a ' command once they have logged in. SolutionEdit the /etc/issue file with the appropriate contents according to your site policy, remove any instances of m , r , s , v or references to the OS platform# echo 'Authorized uses only. All activity may be monitored and reported.' > /etc/issue See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaNon-compliant file(s):
/etc/issue - regex '\\[mrsv]' found - expect '\\[mrsv]' found in the following lines: 2: Kernel \r on an \m lab-preventaNon-compliant file(s):
/etc/issue - regex '\\[mrsv]' found - expect '\\[mrsv]' found in the following lines: 2: Kernel \r on an \m 1.7.3 Ensure remote login warning banner is configured properly - banner textInfoThe contents of the /etc/issue.net file are displayed to users prior to login for remote connections from configured services.Unix-based systems have typically displayed information about the OS release and patch level upon logging in to the system. This information can be useful to developers who are developing software for a particular OS platform. If mingetty(8) supports the following options, they display operating system information: m - machine architecture r - operating system release s - operating system name v - operating system version Rationale: Warning messages inform users who are attempting to login to the system of their legal status regarding the system and must include the name of the organization that owns the system and any monitoring policies that are in place. Displaying OS and patch level information in login banners also has the side effect of providing detailed system information to attackers attempting to target specific exploits of a system. Authorized users can easily get this information by running the ' uname -a ' command once they have logged in. SolutionEdit the /etc/issue.net file with the appropriate contents according to your site policy, remove any instances of m , r , s , v or references to the OS platform# echo 'Authorized uses only. All activity may be monitored and reported.' > /etc/issue.net See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaFirst ERROR: \S Kernel != All activities
\S Kernel \r on an \m lab-preventaFirst ERROR: \S Kernel != All activities
\S Kernel \r on an \m 1.7.3 Ensure remote login warning banner is configured properly - mrsvInfoThe contents of the /etc/issue.net file are displayed to users prior to login for remote connections from configured services.Unix-based systems have typically displayed information about the OS release and patch level upon logging in to the system. This information can be useful to developers who are developing software for a particular OS platform. If mingetty(8) supports the following options, they display operating system information: m - machine architecture r - operating system release s - operating system name v - operating system version Rationale: Warning messages inform users who are attempting to login to the system of their legal status regarding the system and must include the name of the organization that owns the system and any monitoring policies that are in place. Displaying OS and patch level information in login banners also has the side effect of providing detailed system information to attackers attempting to target specific exploits of a system. Authorized users can easily get this information by running the ' uname -a ' command once they have logged in. SolutionEdit the /etc/issue.net file with the appropriate contents according to your site policy, remove any instances of m , r , s , v or references to the OS platform# echo 'Authorized uses only. All activity may be monitored and reported.' > /etc/issue.net See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaNon-compliant file(s):
/etc/issue.net - regex '\\[mrsv]' found - expect '\\[mrsv]' found in the following lines: 2: Kernel \r on an \m lab-preventaNon-compliant file(s):
/etc/issue.net - regex '\\[mrsv]' found - expect '\\[mrsv]' found in the following lines: 2: Kernel \r on an \m 1.9 Ensure updates, patches, and additional security software are installedInfoPeriodically patches are released for included software either due to security flaws or to include additional functionality.Note: Site policy may mandate a testing period before install onto production systems for available updates. Rationale: Newer patches may contain security enhancements that would not be available through the latest full update. As a result, it is recommended that the latest software patches be used to take advantage of the latest functionality. As with any software installation, organizations need to determine if a given update meets their requirements and verify the compatibility and supportability of any additional software against the update revision that is selected. SolutionUse your package manager to update all packages on the system according to site policy.The following command will install all available packages # yum update See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventa The command '/usr/bin/yum check-update && echo 'pass' || echo 'fail'' returned :
Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: edgeuno-bog2.mm.fcix.net * extras: edgeuno-bog2.mm.fcix.net * updates: edgeuno-bog2.mm.fcix.net bind-export-libs.x86_64 32:9.11.4-26.P2.el7_9.15 updates ca-certificates.noarch 2023.2.60_v7.0.306-72.el7_9 updates containerd.io.x86_64 1.6.24-3.1.el7 docker-ce-stable docker-ce.x86_64 3:24.0.6-1.el7 docker-ce-stable docker-ce-cli.x86_64 1:24.0.6-1.el7 docker-ce-stable docker-ce-rootless-extras.x86_64 24.0.6-1.el7 docker-ce-stable docker-compose-plugin.x86_64 2.21.0-1.el7 docker-ce-stable kernel.x86_64 3.10.0-1160.102.1.el7 updates kernel-devel.x86_64 3.10.0-1160.102.1.el7 updates kernel-headers.x86_64 3.10.0-1160.102.1.el7 updates kernel-tools.x86_64 3.10.0-1160.102.1.el7 updates kernel-tools-libs.x86_64 3.10.0-1160.102.1.el7 updates libssh2.x86_64 1.8.0-4.el7_9.1 updates microcode_ctl.x86_64 2:2.1-73.16.el7_9 updates nspr.x86_64 4.35.0-1.el7_9 updates nss.x86_64 3.90.0-2.el7_9 updates nss-softokn.x86_64 3.90.0-6.el7_9 updates nss-softokn-freebl.x86_64 3.90.0-6.el7_9 updates nss-sysinit.x86_64 3.90.0-2.el7_9 updates nss-tools.x86_64 3.90.0-2.el7_9 updates nss-util.x86_64 3.90.0-1.el7_9 updates python-perf.x86_64 [...] lab-preventa The command '/usr/bin/yum check-update && echo 'pass' || echo 'fail'' returned :
Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: edgeuno-bog2.mm.fcix.net * extras: edgeuno-bog2.mm.fcix.net * updates: edgeuno-bog2.mm.fcix.net bind-export-libs.x86_64 32:9.11.4-26.P2.el7_9.15 updates ca-certificates.noarch 2023.2.60_v7.0.306-72.el7_9 updates containerd.io.x86_64 1.6.24-3.1.el7 docker-ce-stable docker-ce.x86_64 3:24.0.6-1.el7 docker-ce-stable docker-ce-cli.x86_64 1:24.0.6-1.el7 docker-ce-stable docker-ce-rootless-extras.x86_64 24.0.6-1.el7 docker-ce-stable docker-compose-plugin.x86_64 2.21.0-1.el7 docker-ce-stable kernel.x86_64 3.10.0-1160.102.1.el7 updates kernel-devel.x86_64 3.10.0-1160.102.1.el7 updates kernel-headers.x86_64 3.10.0-1160.102.1.el7 updates kernel-tools.x86_64 3.10.0-1160.102.1.el7 updates kernel-tools-libs.x86_64 3.10.0-1160.102.1.el7 updates libssh2.x86_64 1.8.0-4.el7_9.1 updates microcode_ctl.x86_64 2:2.1-73.16.el7_9 updates nspr.x86_64 4.35.0-1.el7_9 updates nss.x86_64 3.90.0-2.el7_9 updates nss-softokn.x86_64 3.90.0-6.el7_9 updates nss-softokn-freebl.x86_64 3.90.0-6.el7_9 updates nss-sysinit.x86_64 3.90.0-2.el7_9 updates nss-tools.x86_64 3.90.0-2.el7_9 updates nss-util.x86_64 3.90.0-1.el7_9 updates python-perf.x86_64 [...] 2.2.1.1 Ensure time synchronization is in useInfoSystem time should be synchronized between all systems in an environment. This is typically done by establishing an authoritative time server or set of servers and having all systems synchronize their clocks to them.Note: If another method for time synchronization is being used, this section may be skipped. Only one time synchronization package should be installed Rationale: Time synchronization is important to support time sensitive security mechanisms like Kerberos and also ensures log files have consistent time records across the enterprise, which aids in forensic investigations. SolutionRun One of the following commands to install chrony or NTP:To install chrony, run the following command: # yum install chrony OR To install ntp, run the following command: # yum install ntp Note: On systems where host based time synchronization is available consult your virtualization software documentation and setup host based synchronization. Additional Information: On systems where host based time synchronization is not available, verify that chrony or NTP is installed. On systems where host based time synchronization is available consult your documentation and verify that host based synchronization is in use. See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa2.3.4 Ensure telnet client is not installedInfoThe telnet package contains the telnet client, which allows users to start connections to other systems via the telnet protocol.Rationale: The telnet protocol is insecure and unencrypted. The use of an unencrypted transmission medium could allow an unauthorized user to steal credentials. The ssh package provides an encrypted session and stronger security and is included in most Linux distributions. Impact: Many insecure service clients are used as troubleshooting tools and in testing environments. Uninstalling them can inhibit capability to test and troubleshoot. If they are required it is advisable to remove the clients after use to prevent accidental or intentional misuse. SolutionRun the following command to remove the telnet package:# yum remove telnet See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe local RPM is newer than telnet-0.0.0-0 (telnet-0.17-66.el7)
lab-preventaThe local RPM is newer than telnet-0.0.0-0 (telnet-0.17-66.el7)
3.2.1 Ensure IP forwarding is disabled - ipv4 sysctlInfoThe net.ipv4.ip_forward and net.ipv6.conf.all.forwarding flags are used to tell the system whether it can forward packets or not.Rationale: Setting the flags to 0 ensures that a system with multiple interfaces (for example, a hard proxy), will never be able to forward packets, and therefore, never serve as a router. SolutionRun the following commands to restore the default parameters and set the active kernel parameters:# grep -Els '^s*net.ipv4.ip_forwards*=s*1' /etc/sysctl.conf /etc/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /run/sysctl.d/*.conf | while read filename; do sed -ri 's/^s*(net.ipv4.ip_forwards*)(=)(s*S+b).*$/# *REMOVED* 1/' $filename; done; sysctl -w net.ipv4.ip_forward=0; sysctl -w net.ipv4.route.flush=1 # grep -Els '^s*net.ipv6.conf.all.forwardings*=s*1' /etc/sysctl.conf /etc/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /run/sysctl.d/*.conf | while read filename; do sed -ri 's/^s*(net.ipv6.conf.all.forwardings*)(=)(s*S+b).*$/# *REMOVED* 1/' $filename; done; sysctl -w net.ipv6.conf.all.forwarding=0; sysctl -w net.ipv6.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sysctl net.ipv4.ip_forward' returned :
net.ipv4.ip_forward = 1 lab-preventaThe command '/usr/sbin/sysctl net.ipv4.ip_forward' returned :
net.ipv4.ip_forward = 1 3.2.1 Ensure IP forwarding is disabled - ipv4 sysctlc.conf sysctl.dInfoThe net.ipv4.ip_forward and net.ipv6.conf.all.forwarding flags are used to tell the system whether it can forward packets or not.Rationale: Setting the flags to 0 ensures that a system with multiple interfaces (for example, a hard proxy), will never be able to forward packets, and therefore, never serve as a router. SolutionRun the following commands to restore the default parameters and set the active kernel parameters:# grep -Els '^s*net.ipv4.ip_forwards*=s*1' /etc/sysctl.conf /etc/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /run/sysctl.d/*.conf | while read filename; do sed -ri 's/^s*(net.ipv4.ip_forwards*)(=)(s*S+b).*$/# *REMOVED* 1/' $filename; done; sysctl -w net.ipv4.ip_forward=0; sysctl -w net.ipv4.route.flush=1 # grep -Els '^s*net.ipv6.conf.all.forwardings*=s*1' /etc/sysctl.conf /etc/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /run/sysctl.d/*.conf | while read filename; do sed -ri 's/^s*(net.ipv6.conf.all.forwardings*)(=)(s*S+b).*$/# *REMOVED* 1/' $filename; done; sysctl -w net.ipv6.conf.all.forwarding=0; sysctl -w net.ipv6.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv4\.ip_forward[[:space:]]*=[[:space:]]*0[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail lab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv4\.ip_forward[[:space:]]*=[[:space:]]*0[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail 3.2.1 Ensure IP forwarding is disabled - ipv6 sysctlc.conf sysctl.dInfoThe net.ipv4.ip_forward and net.ipv6.conf.all.forwarding flags are used to tell the system whether it can forward packets or not.Rationale: Setting the flags to 0 ensures that a system with multiple interfaces (for example, a hard proxy), will never be able to forward packets, and therefore, never serve as a router. SolutionRun the following commands to restore the default parameters and set the active kernel parameters:# grep -Els '^s*net.ipv4.ip_forwards*=s*1' /etc/sysctl.conf /etc/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /run/sysctl.d/*.conf | while read filename; do sed -ri 's/^s*(net.ipv4.ip_forwards*)(=)(s*S+b).*$/# *REMOVED* 1/' $filename; done; sysctl -w net.ipv4.ip_forward=0; sysctl -w net.ipv4.route.flush=1 # grep -Els '^s*net.ipv6.conf.all.forwardings*=s*1' /etc/sysctl.conf /etc/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /run/sysctl.d/*.conf | while read filename; do sed -ri 's/^s*(net.ipv6.conf.all.forwardings*)(=)(s*S+b).*$/# *REMOVED* 1/' $filename; done; sysctl -w net.ipv6.conf.all.forwarding=0; sysctl -w net.ipv6.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv6\.conf\.all\.forwarding[[:space:]]*=[[:space:]]*0[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* /usr/lib/sysctl.d/* /run/sysctl.d/* | /usr/bin/awk '{print} END {if (NR > 0) print "pass" ; else print "fail"}'' returned :
fail lab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv6\.conf\.all\.forwarding[[:space:]]*=[[:space:]]*0[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* /usr/lib/sysctl.d/* /run/sysctl.d/* | /usr/bin/awk '{print} END {if (NR > 0) print "pass" ; else print "fail"}'' returned :
fail 3.2.2 Ensure packet redirect sending is disabled - 'net.ipv4.conf.all.send_redirects = 0'InfoICMP Redirects are used to send routing information to other hosts. As a host itself does not act as a router (in a host only configuration), there is no need to send redirects.Rationale: An attacker could use a compromised host to send invalid ICMP redirects to other router devices in an attempt to corrupt routing and have users access a system set up by the attacker as opposed to a valid system. SolutionSet the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file:net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.default.send_redirects = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv4.conf.all.send_redirects=0 # sysctl -w net.ipv4.conf.default.send_redirects=0 # sysctl -w net.ipv4.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sysctl net.ipv4.conf.all.send_redirects' returned :
net.ipv4.conf.all.send_redirects = 1 lab-preventaThe command '/usr/sbin/sysctl net.ipv4.conf.all.send_redirects' returned :
net.ipv4.conf.all.send_redirects = 1 3.2.2 Ensure packet redirect sending is disabled - 'net.ipv4.conf.default.send_redirects = 0'InfoICMP Redirects are used to send routing information to other hosts. As a host itself does not act as a router (in a host only configuration), there is no need to send redirects.Rationale: An attacker could use a compromised host to send invalid ICMP redirects to other router devices in an attempt to corrupt routing and have users access a system set up by the attacker as opposed to a valid system. SolutionSet the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file:net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.default.send_redirects = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv4.conf.all.send_redirects=0 # sysctl -w net.ipv4.conf.default.send_redirects=0 # sysctl -w net.ipv4.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sysctl net.ipv4.conf.default.send_redirects' returned :
net.ipv4.conf.default.send_redirects = 1 lab-preventaThe command '/usr/sbin/sysctl net.ipv4.conf.default.send_redirects' returned :
net.ipv4.conf.default.send_redirects = 1 3.2.2 Ensure packet redirect sending is disabled - files 'net.ipv4.conf.all.send_redirects = 0'InfoICMP Redirects are used to send routing information to other hosts. As a host itself does not act as a router (in a host only configuration), there is no need to send redirects.Rationale: An attacker could use a compromised host to send invalid ICMP redirects to other router devices in an attempt to corrupt routing and have users access a system set up by the attacker as opposed to a valid system. SolutionSet the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file:net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.default.send_redirects = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv4.conf.all.send_redirects=0 # sysctl -w net.ipv4.conf.default.send_redirects=0 # sysctl -w net.ipv4.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv4\.conf\.all\.send_redirects[[:space:]]*=[[:space:]]*0[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail lab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv4\.conf\.all\.send_redirects[[:space:]]*=[[:space:]]*0[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail 3.2.2 Ensure packet redirect sending is disabled - files 'net.ipv4.conf.default.send_redirects = 0'InfoICMP Redirects are used to send routing information to other hosts. As a host itself does not act as a router (in a host only configuration), there is no need to send redirects.Rationale: An attacker could use a compromised host to send invalid ICMP redirects to other router devices in an attempt to corrupt routing and have users access a system set up by the attacker as opposed to a valid system. SolutionSet the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file:net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.default.send_redirects = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv4.conf.all.send_redirects=0 # sysctl -w net.ipv4.conf.default.send_redirects=0 # sysctl -w net.ipv4.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv4\.conf\.default\.send_redirects[[:space:]]*=[[:space:]]*0[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail lab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv4\.conf\.default\.send_redirects[[:space:]]*=[[:space:]]*0[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail 3.3.1 Ensure source routed packets are not accepted - files 'net.ipv4.conf.all.accept_source_route = 0'InfoIn networking, source routing allows a sender to partially or fully specify the route packets take through a network. In contrast, non-source routed packets travel a path determined by routers in the network. In some cases, systems may not be routable or reachable from some locations (e.g. private addresses vs. Internet routable), and so source routed packets would need to be used.Rationale: Setting net.ipv4.conf.all.accept_source_route, net.ipv4.conf.default.accept_source_route, net.ipv6.conf.all.accept_source_route and net.ipv6.conf.default.accept_source_route to 0 disables the system from accepting source routed packets. Assume this system was capable of routing packets to Internet routable addresses on one interface and private addresses on another interface. Assume that the private addresses were not routable to the Internet routable addresses and vice versa. Under normal routing circumstances, an attacker from the Internet routable addresses could not use the system as a way to reach the private address systems. If, however, source routed packets were allowed, they could be used to gain access to the private address systems as the route could be specified, rather than rely on routing protocols that did not allow this routing. SolutionSet the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file:net.ipv4.conf.all.accept_source_route = 0 net.ipv4.conf.default.accept_source_route = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv4.conf.all.accept_source_route=0 # sysctl -w net.ipv4.conf.default.accept_source_route=0 # sysctl -w net.ipv4.route.flush=1 IF IPv6 is not disabled: Set the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file: net.ipv6.conf.all.accept_source_route = 0 net.ipv6.conf.default.accept_source_route = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv6.conf.all.accept_source_route=0 # sysctl -w net.ipv6.conf.default.accept_source_route=0 # sysctl -w net.ipv6.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv4\.conf\.all\.accept_source_route[[:space:]]*=[[:space:]]*0[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail lab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv4\.conf\.all\.accept_source_route[[:space:]]*=[[:space:]]*0[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail 3.3.1 Ensure source routed packets are not accepted - files 'net.ipv4.conf.default.accept_source_route = 0'InfoIn networking, source routing allows a sender to partially or fully specify the route packets take through a network. In contrast, non-source routed packets travel a path determined by routers in the network. In some cases, systems may not be routable or reachable from some locations (e.g. private addresses vs. Internet routable), and so source routed packets would need to be used.Rationale: Setting net.ipv4.conf.all.accept_source_route, net.ipv4.conf.default.accept_source_route, net.ipv6.conf.all.accept_source_route and net.ipv6.conf.default.accept_source_route to 0 disables the system from accepting source routed packets. Assume this system was capable of routing packets to Internet routable addresses on one interface and private addresses on another interface. Assume that the private addresses were not routable to the Internet routable addresses and vice versa. Under normal routing circumstances, an attacker from the Internet routable addresses could not use the system as a way to reach the private address systems. If, however, source routed packets were allowed, they could be used to gain access to the private address systems as the route could be specified, rather than rely on routing protocols that did not allow this routing. SolutionSet the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file:net.ipv4.conf.all.accept_source_route = 0 net.ipv4.conf.default.accept_source_route = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv4.conf.all.accept_source_route=0 # sysctl -w net.ipv4.conf.default.accept_source_route=0 # sysctl -w net.ipv4.route.flush=1 IF IPv6 is not disabled: Set the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file: net.ipv6.conf.all.accept_source_route = 0 net.ipv6.conf.default.accept_source_route = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv6.conf.all.accept_source_route=0 # sysctl -w net.ipv6.conf.default.accept_source_route=0 # sysctl -w net.ipv6.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv4\.conf\.default\.accept_source_route[[:space:]]*=[[:space:]]*0[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail lab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv4\.conf\.default\.accept_source_route[[:space:]]*=[[:space:]]*0[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail 3.3.1 Ensure source routed packets are not accepted - files 'net.ipv6.conf.all.accept_source_route = 0'InfoIn networking, source routing allows a sender to partially or fully specify the route packets take through a network. In contrast, non-source routed packets travel a path determined by routers in the network. In some cases, systems may not be routable or reachable from some locations (e.g. private addresses vs. Internet routable), and so source routed packets would need to be used.Rationale: Setting net.ipv4.conf.all.accept_source_route, net.ipv4.conf.default.accept_source_route, net.ipv6.conf.all.accept_source_route and net.ipv6.conf.default.accept_source_route to 0 disables the system from accepting source routed packets. Assume this system was capable of routing packets to Internet routable addresses on one interface and private addresses on another interface. Assume that the private addresses were not routable to the Internet routable addresses and vice versa. Under normal routing circumstances, an attacker from the Internet routable addresses could not use the system as a way to reach the private address systems. If, however, source routed packets were allowed, they could be used to gain access to the private address systems as the route could be specified, rather than rely on routing protocols that did not allow this routing. SolutionSet the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file:net.ipv4.conf.all.accept_source_route = 0 net.ipv4.conf.default.accept_source_route = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv4.conf.all.accept_source_route=0 # sysctl -w net.ipv4.conf.default.accept_source_route=0 # sysctl -w net.ipv4.route.flush=1 IF IPv6 is not disabled: Set the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file: net.ipv6.conf.all.accept_source_route = 0 net.ipv6.conf.default.accept_source_route = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv6.conf.all.accept_source_route=0 # sysctl -w net.ipv6.conf.default.accept_source_route=0 # sysctl -w net.ipv6.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv6\.conf\.all\.accept_source_route[[:space:]]*=[[:space:]]*0[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail lab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv6\.conf\.all\.accept_source_route[[:space:]]*=[[:space:]]*0[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail 3.3.1 Ensure source routed packets are not accepted - files 'net.ipv6.conf.default.accept_source_route = 0'InfoIn networking, source routing allows a sender to partially or fully specify the route packets take through a network. In contrast, non-source routed packets travel a path determined by routers in the network. In some cases, systems may not be routable or reachable from some locations (e.g. private addresses vs. Internet routable), and so source routed packets would need to be used.Rationale: Setting net.ipv4.conf.all.accept_source_route, net.ipv4.conf.default.accept_source_route, net.ipv6.conf.all.accept_source_route and net.ipv6.conf.default.accept_source_route to 0 disables the system from accepting source routed packets. Assume this system was capable of routing packets to Internet routable addresses on one interface and private addresses on another interface. Assume that the private addresses were not routable to the Internet routable addresses and vice versa. Under normal routing circumstances, an attacker from the Internet routable addresses could not use the system as a way to reach the private address systems. If, however, source routed packets were allowed, they could be used to gain access to the private address systems as the route could be specified, rather than rely on routing protocols that did not allow this routing. SolutionSet the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file:net.ipv4.conf.all.accept_source_route = 0 net.ipv4.conf.default.accept_source_route = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv4.conf.all.accept_source_route=0 # sysctl -w net.ipv4.conf.default.accept_source_route=0 # sysctl -w net.ipv4.route.flush=1 IF IPv6 is not disabled: Set the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file: net.ipv6.conf.all.accept_source_route = 0 net.ipv6.conf.default.accept_source_route = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv6.conf.all.accept_source_route=0 # sysctl -w net.ipv6.conf.default.accept_source_route=0 # sysctl -w net.ipv6.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv6\.conf\.default\.accept_source_route[[:space:]]*=[[:space:]]*0[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail lab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv6\.conf\.default\.accept_source_route[[:space:]]*=[[:space:]]*0[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail 3.3.2 Ensure ICMP redirects are not accepted - 'net.ipv4.conf.default.accept_redirects = 0'InfoICMP redirect messages are packets that convey routing information and tell your host (acting as a router) to send packets via an alternate path. It is a way of allowing an outside routing device to update your system routing tables. By setting net.ipv4.conf.all.accept_redirects and net.ipv6.conf.all.accept_redirects to 0, the system will not accept any ICMP redirect messages, and therefore, won't allow outsiders to update the system's routing tables.Rationale: Attackers could use bogus ICMP redirect messages to maliciously alter the system routing tables and get them to send packets to incorrect networks and allow your system packets to be captured. SolutionSet the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file:net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv4.conf.all.accept_redirects=0 # sysctl -w net.ipv4.conf.default.accept_redirects=0 # sysctl -w net.ipv4.route.flush=1 IF IPv6 is not disabled Set the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file: net.ipv6.conf.all.accept_redirects = 0 net.ipv6.conf.default.accept_redirects = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv6.conf.all.accept_redirects=0 # sysctl -w net.ipv6.conf.default.accept_redirects=0 # sysctl -w net.ipv6.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sysctl net.ipv4.conf.default.accept_redirects' returned :
net.ipv4.conf.default.accept_redirects = 1 lab-preventaThe command '/usr/sbin/sysctl net.ipv4.conf.default.accept_redirects' returned :
net.ipv4.conf.default.accept_redirects = 1 3.3.2 Ensure ICMP redirects are not accepted - 'net.ipv6.conf.all.accept_redirects = 0'InfoICMP redirect messages are packets that convey routing information and tell your host (acting as a router) to send packets via an alternate path. It is a way of allowing an outside routing device to update your system routing tables. By setting net.ipv4.conf.all.accept_redirects and net.ipv6.conf.all.accept_redirects to 0, the system will not accept any ICMP redirect messages, and therefore, won't allow outsiders to update the system's routing tables.Rationale: Attackers could use bogus ICMP redirect messages to maliciously alter the system routing tables and get them to send packets to incorrect networks and allow your system packets to be captured. SolutionSet the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file:net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv4.conf.all.accept_redirects=0 # sysctl -w net.ipv4.conf.default.accept_redirects=0 # sysctl -w net.ipv4.route.flush=1 IF IPv6 is not disabled Set the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file: net.ipv6.conf.all.accept_redirects = 0 net.ipv6.conf.default.accept_redirects = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv6.conf.all.accept_redirects=0 # sysctl -w net.ipv6.conf.default.accept_redirects=0 # sysctl -w net.ipv6.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sysctl net.ipv6.conf.all.accept_redirects' returned :
net.ipv6.conf.all.accept_redirects = 1 lab-preventaThe command '/usr/sbin/sysctl net.ipv6.conf.all.accept_redirects' returned :
net.ipv6.conf.all.accept_redirects = 1 3.3.2 Ensure ICMP redirects are not accepted - 'net.ipv6.conf.default.accept_redirects = 0'InfoICMP redirect messages are packets that convey routing information and tell your host (acting as a router) to send packets via an alternate path. It is a way of allowing an outside routing device to update your system routing tables. By setting net.ipv4.conf.all.accept_redirects and net.ipv6.conf.all.accept_redirects to 0, the system will not accept any ICMP redirect messages, and therefore, won't allow outsiders to update the system's routing tables.Rationale: Attackers could use bogus ICMP redirect messages to maliciously alter the system routing tables and get them to send packets to incorrect networks and allow your system packets to be captured. SolutionSet the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file:net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv4.conf.all.accept_redirects=0 # sysctl -w net.ipv4.conf.default.accept_redirects=0 # sysctl -w net.ipv4.route.flush=1 IF IPv6 is not disabled Set the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file: net.ipv6.conf.all.accept_redirects = 0 net.ipv6.conf.default.accept_redirects = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv6.conf.all.accept_redirects=0 # sysctl -w net.ipv6.conf.default.accept_redirects=0 # sysctl -w net.ipv6.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sysctl net.ipv6.conf.default.accept_redirects' returned :
net.ipv6.conf.default.accept_redirects = 1 lab-preventaThe command '/usr/sbin/sysctl net.ipv6.conf.default.accept_redirects' returned :
net.ipv6.conf.default.accept_redirects = 1 3.3.2 Ensure ICMP redirects are not accepted - files 'net.ipv4.conf.all.accept_redirects = 0'InfoICMP redirect messages are packets that convey routing information and tell your host (acting as a router) to send packets via an alternate path. It is a way of allowing an outside routing device to update your system routing tables. By setting net.ipv4.conf.all.accept_redirects and net.ipv6.conf.all.accept_redirects to 0, the system will not accept any ICMP redirect messages, and therefore, won't allow outsiders to update the system's routing tables.Rationale: Attackers could use bogus ICMP redirect messages to maliciously alter the system routing tables and get them to send packets to incorrect networks and allow your system packets to be captured. SolutionSet the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file:net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv4.conf.all.accept_redirects=0 # sysctl -w net.ipv4.conf.default.accept_redirects=0 # sysctl -w net.ipv4.route.flush=1 IF IPv6 is not disabled Set the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file: net.ipv6.conf.all.accept_redirects = 0 net.ipv6.conf.default.accept_redirects = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv6.conf.all.accept_redirects=0 # sysctl -w net.ipv6.conf.default.accept_redirects=0 # sysctl -w net.ipv6.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv4\.conf\.all\.accept_redirects[[:space:]]*=[[:space:]]*0[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail lab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv4\.conf\.all\.accept_redirects[[:space:]]*=[[:space:]]*0[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail 3.3.2 Ensure ICMP redirects are not accepted - files 'net.ipv4.conf.default.accept_redirects = 0'InfoICMP redirect messages are packets that convey routing information and tell your host (acting as a router) to send packets via an alternate path. It is a way of allowing an outside routing device to update your system routing tables. By setting net.ipv4.conf.all.accept_redirects and net.ipv6.conf.all.accept_redirects to 0, the system will not accept any ICMP redirect messages, and therefore, won't allow outsiders to update the system's routing tables.Rationale: Attackers could use bogus ICMP redirect messages to maliciously alter the system routing tables and get them to send packets to incorrect networks and allow your system packets to be captured. SolutionSet the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file:net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv4.conf.all.accept_redirects=0 # sysctl -w net.ipv4.conf.default.accept_redirects=0 # sysctl -w net.ipv4.route.flush=1 IF IPv6 is not disabled Set the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file: net.ipv6.conf.all.accept_redirects = 0 net.ipv6.conf.default.accept_redirects = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv6.conf.all.accept_redirects=0 # sysctl -w net.ipv6.conf.default.accept_redirects=0 # sysctl -w net.ipv6.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv4\.conf\.default\.accept_redirects[[:space:]]*=[[:space:]]*0[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail lab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv4\.conf\.default\.accept_redirects[[:space:]]*=[[:space:]]*0[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail 3.3.2 Ensure ICMP redirects are not accepted - files 'net.ipv6.conf.all.accept_redirects = 0'InfoICMP redirect messages are packets that convey routing information and tell your host (acting as a router) to send packets via an alternate path. It is a way of allowing an outside routing device to update your system routing tables. By setting net.ipv4.conf.all.accept_redirects and net.ipv6.conf.all.accept_redirects to 0, the system will not accept any ICMP redirect messages, and therefore, won't allow outsiders to update the system's routing tables.Rationale: Attackers could use bogus ICMP redirect messages to maliciously alter the system routing tables and get them to send packets to incorrect networks and allow your system packets to be captured. SolutionSet the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file:net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv4.conf.all.accept_redirects=0 # sysctl -w net.ipv4.conf.default.accept_redirects=0 # sysctl -w net.ipv4.route.flush=1 IF IPv6 is not disabled Set the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file: net.ipv6.conf.all.accept_redirects = 0 net.ipv6.conf.default.accept_redirects = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv6.conf.all.accept_redirects=0 # sysctl -w net.ipv6.conf.default.accept_redirects=0 # sysctl -w net.ipv6.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv6\.conf\.all\.accept_redirects[[:space:]]*=[[:space:]]*0[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail lab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv6\.conf\.all\.accept_redirects[[:space:]]*=[[:space:]]*0[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail 3.3.2 Ensure ICMP redirects are not accepted - files 'net.ipv6.conf.default.accept_redirects = 0'InfoICMP redirect messages are packets that convey routing information and tell your host (acting as a router) to send packets via an alternate path. It is a way of allowing an outside routing device to update your system routing tables. By setting net.ipv4.conf.all.accept_redirects and net.ipv6.conf.all.accept_redirects to 0, the system will not accept any ICMP redirect messages, and therefore, won't allow outsiders to update the system's routing tables.Rationale: Attackers could use bogus ICMP redirect messages to maliciously alter the system routing tables and get them to send packets to incorrect networks and allow your system packets to be captured. SolutionSet the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file:net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv4.conf.all.accept_redirects=0 # sysctl -w net.ipv4.conf.default.accept_redirects=0 # sysctl -w net.ipv4.route.flush=1 IF IPv6 is not disabled Set the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file: net.ipv6.conf.all.accept_redirects = 0 net.ipv6.conf.default.accept_redirects = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv6.conf.all.accept_redirects=0 # sysctl -w net.ipv6.conf.default.accept_redirects=0 # sysctl -w net.ipv6.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv6\.conf\.default\.accept_redirects[[:space:]]*=[[:space:]]*0[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail lab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv6\.conf\.default\.accept_redirects[[:space:]]*=[[:space:]]*0[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail 3.3.3 Ensure secure ICMP redirects are not accepted - 'net.ipv4.conf.all.secure_redirects = 0'InfoSecure ICMP redirects are the same as ICMP redirects, except they come from gateways listed on the default gateway list. It is assumed that these gateways are known to your system, and that they are likely to be secure.Rationale: It is still possible for even known gateways to be compromised. Setting net.ipv4.conf.all.secure_redirects to 0 protects the system from routing table updates by possibly compromised known gateways. SolutionSet the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file:net.ipv4.conf.all.secure_redirects = 0 net.ipv4.conf.default.secure_redirects = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv4.conf.all.secure_redirects=0 # sysctl -w net.ipv4.conf.default.secure_redirects=0 # sysctl -w net.ipv4.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sysctl net.ipv4.conf.all.secure_redirects' returned :
net.ipv4.conf.all.secure_redirects = 1 lab-preventaThe command '/usr/sbin/sysctl net.ipv4.conf.all.secure_redirects' returned :
net.ipv4.conf.all.secure_redirects = 1 3.3.3 Ensure secure ICMP redirects are not accepted - 'net.ipv4.conf.default.secure_redirects = 0'InfoSecure ICMP redirects are the same as ICMP redirects, except they come from gateways listed on the default gateway list. It is assumed that these gateways are known to your system, and that they are likely to be secure.Rationale: It is still possible for even known gateways to be compromised. Setting net.ipv4.conf.all.secure_redirects to 0 protects the system from routing table updates by possibly compromised known gateways. SolutionSet the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file:net.ipv4.conf.all.secure_redirects = 0 net.ipv4.conf.default.secure_redirects = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv4.conf.all.secure_redirects=0 # sysctl -w net.ipv4.conf.default.secure_redirects=0 # sysctl -w net.ipv4.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sysctl net.ipv4.conf.default.secure_redirects' returned :
net.ipv4.conf.default.secure_redirects = 1 lab-preventaThe command '/usr/sbin/sysctl net.ipv4.conf.default.secure_redirects' returned :
net.ipv4.conf.default.secure_redirects = 1 3.3.3 Ensure secure ICMP redirects are not accepted - files 'net.ipv4.conf.all.secure_redirects = 0'InfoSecure ICMP redirects are the same as ICMP redirects, except they come from gateways listed on the default gateway list. It is assumed that these gateways are known to your system, and that they are likely to be secure.Rationale: It is still possible for even known gateways to be compromised. Setting net.ipv4.conf.all.secure_redirects to 0 protects the system from routing table updates by possibly compromised known gateways. SolutionSet the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file:net.ipv4.conf.all.secure_redirects = 0 net.ipv4.conf.default.secure_redirects = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv4.conf.all.secure_redirects=0 # sysctl -w net.ipv4.conf.default.secure_redirects=0 # sysctl -w net.ipv4.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv4\.conf\.all\.secure_redirects[[:space:]]*=[[:space:]]*0[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail lab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv4\.conf\.all\.secure_redirects[[:space:]]*=[[:space:]]*0[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail 3.3.3 Ensure secure ICMP redirects are not accepted - files 'net.ipv4.conf.default.secure_redirects = 0'InfoSecure ICMP redirects are the same as ICMP redirects, except they come from gateways listed on the default gateway list. It is assumed that these gateways are known to your system, and that they are likely to be secure.Rationale: It is still possible for even known gateways to be compromised. Setting net.ipv4.conf.all.secure_redirects to 0 protects the system from routing table updates by possibly compromised known gateways. SolutionSet the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file:net.ipv4.conf.all.secure_redirects = 0 net.ipv4.conf.default.secure_redirects = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv4.conf.all.secure_redirects=0 # sysctl -w net.ipv4.conf.default.secure_redirects=0 # sysctl -w net.ipv4.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv4\.conf\.default\.secure_redirects[[:space:]]*=[[:space:]]*0[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail lab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv4\.conf\.default\.secure_redirects[[:space:]]*=[[:space:]]*0[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail 3.3.4 Ensure suspicious packets are logged - 'net.ipv4.conf.all.log_martians = 1'InfoWhen enabled, this feature logs packets with un-routable source addresses to the kernel log.Rationale: Enabling this feature and logging these packets allows an administrator to investigate the possibility that an attacker is sending spoofed packets to their system. SolutionSet the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file:net.ipv4.conf.all.log_martians = 1 net.ipv4.conf.default.log_martians = 1 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv4.conf.all.log_martians=1 # sysctl -w net.ipv4.conf.default.log_martians=1 # sysctl -w net.ipv4.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sysctl net.ipv4.conf.all.log_martians' returned :
net.ipv4.conf.all.log_martians = 0 lab-preventaThe command '/usr/sbin/sysctl net.ipv4.conf.all.log_martians' returned :
net.ipv4.conf.all.log_martians = 0 3.3.4 Ensure suspicious packets are logged - 'net.ipv4.conf.default.log_martians = 1'InfoWhen enabled, this feature logs packets with un-routable source addresses to the kernel log.Rationale: Enabling this feature and logging these packets allows an administrator to investigate the possibility that an attacker is sending spoofed packets to their system. SolutionSet the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file:net.ipv4.conf.all.log_martians = 1 net.ipv4.conf.default.log_martians = 1 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv4.conf.all.log_martians=1 # sysctl -w net.ipv4.conf.default.log_martians=1 # sysctl -w net.ipv4.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sysctl net.ipv4.conf.default.log_martians' returned :
net.ipv4.conf.default.log_martians = 0 lab-preventaThe command '/usr/sbin/sysctl net.ipv4.conf.default.log_martians' returned :
net.ipv4.conf.default.log_martians = 0 3.3.4 Ensure suspicious packets are logged - files 'net.ipv4.conf.all.log_martians = 1'InfoWhen enabled, this feature logs packets with un-routable source addresses to the kernel log.Rationale: Enabling this feature and logging these packets allows an administrator to investigate the possibility that an attacker is sending spoofed packets to their system. SolutionSet the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file:net.ipv4.conf.all.log_martians = 1 net.ipv4.conf.default.log_martians = 1 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv4.conf.all.log_martians=1 # sysctl -w net.ipv4.conf.default.log_martians=1 # sysctl -w net.ipv4.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv4\.conf\.all\.log_martians[[:space:]]*=[[:space:]]*1[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail lab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv4\.conf\.all\.log_martians[[:space:]]*=[[:space:]]*1[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail 3.3.4 Ensure suspicious packets are logged - files 'net.ipv4.conf.default.log_martians = 1'InfoWhen enabled, this feature logs packets with un-routable source addresses to the kernel log.Rationale: Enabling this feature and logging these packets allows an administrator to investigate the possibility that an attacker is sending spoofed packets to their system. SolutionSet the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file:net.ipv4.conf.all.log_martians = 1 net.ipv4.conf.default.log_martians = 1 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv4.conf.all.log_martians=1 # sysctl -w net.ipv4.conf.default.log_martians=1 # sysctl -w net.ipv4.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv4\.conf\.default\.log_martians[[:space:]]*=[[:space:]]*1[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail lab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv4\.conf\.default\.log_martians[[:space:]]*=[[:space:]]*1[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail 3.3.5 Ensure broadcast ICMP requests are ignored - sysctl.conf sysctl.dInfoSetting net.ipv4.icmp_echo_ignore_broadcasts to 1 will cause the system to ignore all ICMP echo and timestamp requests to broadcast and multicast addresses.Rationale: Accepting ICMP echo and timestamp requests with broadcast or multicast destinations for your network could be used to trick your host into starting (or participating) in a Smurf attack. A Smurf attack relies on an attacker sending large amounts of ICMP broadcast messages with a spoofed source address. All hosts receiving this message and responding would send echo-reply messages back to the spoofed address, which is probably not routable. If many hosts respond to the packets, the amount of traffic on the network could be significantly multiplied. SolutionSet the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file:net.ipv4.icmp_echo_ignore_broadcasts = 1 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1 # sysctl -w net.ipv4.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv4\.icmp_echo_ignore_broadcasts[[:space:]]*=[[:space:]]*1[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail lab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv4\.icmp_echo_ignore_broadcasts[[:space:]]*=[[:space:]]*1[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail 3.3.6 Ensure bogus ICMP responses are ignored - sysctl.conf sysctl.dInfoSetting icmp_ignore_bogus_error_responses to 1 prevents the kernel from logging bogus responses (RFC-1122 non-compliant) from broadcast reframes, keeping file systems from filling up with useless log messages.Rationale: Some routers (and some attackers) will send responses that violate RFC-1122 and attempt to fill up a log file system with many useless error messages. SolutionSet the following parameter in /etc/sysctl.conf or a /etc/sysctl.d/* file:net.ipv4.icmp_ignore_bogus_error_responses = 1 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv4.icmp_ignore_bogus_error_responses=1 # sysctl -w net.ipv4.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv4\.icmp_ignore_bogus_error_responses[[:space:]]*=[[:space:]]*1[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail lab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv4\.icmp_ignore_bogus_error_responses[[:space:]]*=[[:space:]]*1[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail 3.3.7 Ensure Reverse Path Filtering is enabled - files 'net.ipv4.conf.all.rp_filter = 1'InfoSetting net.ipv4.conf.all.rp_filter and net.ipv4.conf.default.rp_filter to 1 forces the Linux kernel to utilize reverse path filtering on a received packet to determine if the packet was valid. Essentially, with reverse path filtering, if the return packet does not go out the same interface that the corresponding source packet came from, the packet is dropped (and logged if log_martians is set).Rationale: Setting these flags is a good way to deter attackers from sending your system bogus packets that cannot be responded to. One instance where this feature breaks down is if asymmetrical routing is employed. This would occur when using dynamic routing protocols (bgp, ospf, etc) on your system. If you are using asymmetrical routing on your system, you will not be able to enable this feature without breaking the routing. SolutionSet the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file:net.ipv4.conf.all.rp_filter = 1 net.ipv4.conf.default.rp_filter = 1 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv4.conf.all.rp_filter=1 # sysctl -w net.ipv4.conf.default.rp_filter=1 # sysctl -w net.ipv4.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv4\.conf\.all\.rp_filter[[:space:]]*=[[:space:]]*1[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail lab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv4\.conf\.all\.rp_filter[[:space:]]*=[[:space:]]*1[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail 3.3.7 Ensure Reverse Path Filtering is enabled - files 'net.ipv4.conf.default.rp_filter = 1'InfoSetting net.ipv4.conf.all.rp_filter and net.ipv4.conf.default.rp_filter to 1 forces the Linux kernel to utilize reverse path filtering on a received packet to determine if the packet was valid. Essentially, with reverse path filtering, if the return packet does not go out the same interface that the corresponding source packet came from, the packet is dropped (and logged if log_martians is set).Rationale: Setting these flags is a good way to deter attackers from sending your system bogus packets that cannot be responded to. One instance where this feature breaks down is if asymmetrical routing is employed. This would occur when using dynamic routing protocols (bgp, ospf, etc) on your system. If you are using asymmetrical routing on your system, you will not be able to enable this feature without breaking the routing. SolutionSet the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file:net.ipv4.conf.all.rp_filter = 1 net.ipv4.conf.default.rp_filter = 1 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv4.conf.all.rp_filter=1 # sysctl -w net.ipv4.conf.default.rp_filter=1 # sysctl -w net.ipv4.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv4\.conf\.default\.rp_filter[[:space:]]*=[[:space:]]*1[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail lab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv4\.conf\.default\.rp_filter[[:space:]]*=[[:space:]]*1[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail 3.3.8 Ensure TCP SYN Cookies is enabled - sysctl.conf sysctl.dInfoWhen tcp_syncookies is set, the kernel will handle TCP SYN packets normally until the half-open connection queue is full, at which time, the SYN cookie functionality kicks in. SYN cookies work by not using the SYN queue at all. Instead, the kernel simply replies to the SYN with a SYN|ACK, but will include a specially crafted TCP sequence number that encodes the source and destination IP address and port number and the time the packet was sent. A legitimate connection would send the ACK packet of the three way handshake with the specially crafted sequence number. This allows the system to verify that it has received a valid response to a SYN cookie and allow the connection, even though there is no corresponding SYN in the queue.Rationale: Attackers use SYN flood attacks to perform a denial of service attacked on a system by sending many SYN packets without completing the three way handshake. This will quickly use up slots in the kernel's half-open connection queue and prevent legitimate connections from succeeding. SYN cookies allow the system to keep accepting valid connections, even if under a denial of service attack. SolutionSet the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file:net.ipv4.tcp_syncookies = 1 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv4.tcp_syncookies=1 # sysctl -w net.ipv4.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv4\.tcp_syncookies[[:space:]]*=[[:space:]]*1[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail lab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv4\.tcp_syncookies[[:space:]]*=[[:space:]]*1[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail 3.3.9 Ensure IPv6 router advertisements are not accepted - 'net.ipv6.conf.all.accept_ra = 0'InfoThis setting disables the system's ability to accept IPv6 router advertisements.Rationale: It is recommended that systems do not accept router advertisements as they could be tricked into routing traffic to compromised machines. Setting hard routes within the system (usually a single default route to a trusted router) protects the system from bad routes. SolutionIF IPv6 is enabled:Set the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file: net.ipv6.conf.all.accept_ra = 0 net.ipv6.conf.default.accept_ra = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv6.conf.all.accept_ra=0 # sysctl -w net.ipv6.conf.default.accept_ra=0 # sysctl -w net.ipv6.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sysctl net.ipv6.conf.all.accept_ra' returned :
net.ipv6.conf.all.accept_ra = 1 lab-preventaThe command '/usr/sbin/sysctl net.ipv6.conf.all.accept_ra' returned :
net.ipv6.conf.all.accept_ra = 1 3.3.9 Ensure IPv6 router advertisements are not accepted - 'net.ipv6.conf.default.accept_ra = 0'InfoThis setting disables the system's ability to accept IPv6 router advertisements.Rationale: It is recommended that systems do not accept router advertisements as they could be tricked into routing traffic to compromised machines. Setting hard routes within the system (usually a single default route to a trusted router) protects the system from bad routes. SolutionIF IPv6 is enabled:Set the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file: net.ipv6.conf.all.accept_ra = 0 net.ipv6.conf.default.accept_ra = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv6.conf.all.accept_ra=0 # sysctl -w net.ipv6.conf.default.accept_ra=0 # sysctl -w net.ipv6.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sysctl net.ipv6.conf.default.accept_ra' returned :
net.ipv6.conf.default.accept_ra = 1 lab-preventaThe command '/usr/sbin/sysctl net.ipv6.conf.default.accept_ra' returned :
net.ipv6.conf.default.accept_ra = 1 3.3.9 Ensure IPv6 router advertisements are not accepted - files 'net.ipv6.conf.all.accept_ra = 0'InfoThis setting disables the system's ability to accept IPv6 router advertisements.Rationale: It is recommended that systems do not accept router advertisements as they could be tricked into routing traffic to compromised machines. Setting hard routes within the system (usually a single default route to a trusted router) protects the system from bad routes. SolutionIF IPv6 is enabled:Set the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file: net.ipv6.conf.all.accept_ra = 0 net.ipv6.conf.default.accept_ra = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv6.conf.all.accept_ra=0 # sysctl -w net.ipv6.conf.default.accept_ra=0 # sysctl -w net.ipv6.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv6\.conf\.all\.accept_ra[[:space:]]*=[[:space:]]*0[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail lab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv6\.conf\.all\.accept_ra[[:space:]]*=[[:space:]]*0[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail 3.3.9 Ensure IPv6 router advertisements are not accepted - files 'net.ipv6.conf.default.accept_ra = 0'InfoThis setting disables the system's ability to accept IPv6 router advertisements.Rationale: It is recommended that systems do not accept router advertisements as they could be tricked into routing traffic to compromised machines. Setting hard routes within the system (usually a single default route to a trusted router) protects the system from bad routes. SolutionIF IPv6 is enabled:Set the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file: net.ipv6.conf.all.accept_ra = 0 net.ipv6.conf.default.accept_ra = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv6.conf.all.accept_ra=0 # sysctl -w net.ipv6.conf.default.accept_ra=0 # sysctl -w net.ipv6.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv6\.conf\.default\.accept_ra[[:space:]]*=[[:space:]]*0[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail lab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*net\.ipv6\.conf\.default\.accept_ra[[:space:]]*=[[:space:]]*0[[:space:]]*$' /etc/sysctl.conf /etc/sysctl.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail 4.2.1.3 Ensure rsyslog default file permissions are configuredInfoRSyslog will create logfiles that do not already exist on the system. This setting controls what permissions will be applied to these newly created files.Rationale: It is important to ensure that log files have the correct permissions to ensure that sensitive data is archived and protected. Impact: The systems global umask could override, but only making the file permissions stricter, what is configured in RSyslog with the FileCreateMode directive. RSyslog also has it's own $umask directive that can alter the intended file creation mode. In addition, consideration should be given to how FileCreateMode is used. Thus it is critical to ensure that the intended file creation mode is not overridden with less restrictive settings in /etc/rsyslog.conf, /etc/rsyslog.d/*conf files and that FileCreateMode is set before any file is created. SolutionEdit either /etc/rsyslog.conf or a dedicated .conf file in /etc/rsyslog.d/ and set $FileCreateMode to 0640 or more restrictive:$FileCreateMode 0640 Restart the service: # systemctl restart rsyslog See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaNo matching files were found
Less than 1 matches of regex found lab-preventaNo matching files were found
Less than 1 matches of regex found 4.2.1.4 Ensure logging is configuredInfoThe /etc/rsyslog.conf and /etc/rsyslog.d/*.conf files specifies rules for logging and which files are to be used to log certain classes of messages.Rationale: A great deal of important security-related information is sent via rsyslog (e.g., successful and failed su attempts, failed login attempts, root login attempts, etc.). SolutionEdit the following lines in the /etc/rsyslog.conf and /etc/rsyslog.d/*.conf files as appropriate for your environment.NOTE: The below configuration is shown for example purposes only. Due care should be given to how the organization wish to store log data. *.emerg :omusrmsg:* auth,authpriv.* /var/log/secure mail.* -/var/log/mail mail.info -/var/log/mail.info mail.warning -/var/log/mail.warn mail.err /var/log/mail.err cron.* /var/log/cron *.=warning;*.=err -/var/log/warn *.crit /var/log/warn *.*;mail.none;news.none -/var/log/messages local0,local1.* -/var/log/localmessages local2,local3.* -/var/log/localmessages local4,local5.* -/var/log/localmessages local6,local7.* -/var/log/localmessages Run the following command to reload the rsyslogd configuration: # systemctl restart rsyslog See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventa All of the following must pass to satisfy this requirement:
------------------------- PASSED - 4.2.1.4 Ensure logging is configured - '*.emerg :omusrmsg:*' Compliant file(s): /etc/rsyslog.conf - regex '^[\s]*\*\.emerg' found - expect '\*\.emerg\s+:omusrmsg:\*$' found in the following lines: 67: *.emerg :omusrmsg:* /etc/rsyslog.d/listen.conf - regex not found ------------------------- FAILED - 4.2.1.4 Ensure logging is configured - 'auth,authpriv.* /var/log/secure' No matching files were found Less than 1 matches of regex found ------------------------- FAILED - 4.2.1.4 Ensure logging is configured - 'mail.* -/var/log/mail' Non-compliant file(s): /etc/rsyslog.conf - regex '^[\s]*mail\.\*' found - expect 'mail\.\*[\s]+-/var/log/mail[\s]*$' not found in the following lines: 60: mail.* -/var/log/maillog ------------------------- FAILED - 4.2.1.4 Ensure logging is configured - 'mail.info -/var/log/mail.info' No matching files were found Less than 1 matches of regex found ------------------------- FAILED - 4.2.1.4 Ensure logging is configured - 'mail.warning -/var/log/mail.warn' No matching files were found Less than 1 matches of regex found ------------------------- FAILED - 4.2.1.4 Ensure logging is configured - 'mail.err /var/log/mail.err' No matching files were found Less than 1 matches of regex found ------------------------- FAILED - 4.2.1.4 Ensure logging is configured - 'cron.* /var/log/cron' Non-compliant file(s): /etc/rsyslog.conf - regex '^[\s]*cron\.*' found - expect 'cron\.*[\s]+/var/log/cron[\s]*$' not found in the following lines: 64: cron.* /var/log/cron ------------------------- FAILED - 4.2.1.4 Ensure logging is configured - '*.=warning;*.=err [...] lab-preventa All of the following must pass to satisfy this requirement:
------------------------- PASSED - 4.2.1.4 Ensure logging is configured - '*.emerg :omusrmsg:*' Compliant file(s): /etc/rsyslog.conf - regex '^[\s]*\*\.emerg' found - expect '\*\.emerg\s+:omusrmsg:\*$' found in the following lines: 67: *.emerg :omusrmsg:* /etc/rsyslog.d/listen.conf - regex not found ------------------------- FAILED - 4.2.1.4 Ensure logging is configured - 'auth,authpriv.* /var/log/secure' No matching files were found Less than 1 matches of regex found ------------------------- FAILED - 4.2.1.4 Ensure logging is configured - 'mail.* -/var/log/mail' Non-compliant file(s): /etc/rsyslog.conf - regex '^[\s]*mail\.\*' found - expect 'mail\.\*[\s]+-/var/log/mail[\s]*$' not found in the following lines: 60: mail.* -/var/log/maillog ------------------------- FAILED - 4.2.1.4 Ensure logging is configured - 'mail.info -/var/log/mail.info' No matching files were found Less than 1 matches of regex found ------------------------- FAILED - 4.2.1.4 Ensure logging is configured - 'mail.warning -/var/log/mail.warn' No matching files were found Less than 1 matches of regex found ------------------------- FAILED - 4.2.1.4 Ensure logging is configured - 'mail.err /var/log/mail.err' No matching files were found Less than 1 matches of regex found ------------------------- FAILED - 4.2.1.4 Ensure logging is configured - 'cron.* /var/log/cron' Non-compliant file(s): /etc/rsyslog.conf - regex '^[\s]*cron\.*' found - expect 'cron\.*[\s]+/var/log/cron[\s]*$' not found in the following lines: 64: cron.* /var/log/cron ------------------------- FAILED - 4.2.1.4 Ensure logging is configured - '*.=warning;*.=err [...] 4.2.1.5 Ensure rsyslog is configured to send logs to a remote log hostInfoRSyslog supports the ability to send log events it gathers to a remote log host or to receive messages from remote hosts, thus enabling centralised log management.Rationale: Storing log data on a remote host protects log integrity from local attacks. If an attacker gains root access on the local system, they could tamper with or remove log data that is stored on the local system. SolutionEdit the /etc/rsyslog.conf and /etc/rsyslog.d/*.conf files and add the following line (where loghost.example.com is the name of your central log host). The target directive may either be a fully qualified domain name or an IP address.*.* action(type='omfwd' target='192.168.2.100' port='514' protocol='tcp' action.resumeRetryCount='100' queue.type='LinkedList' queue.size='1000') Run the following command to reload the rsyslogd configuration: # systemctl restart rsyslog See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaOne of the following must pass to satisfy this requirement:
------------------------- FAILED - rsyslog old format No matching files were found Less than 1 matches of regex found ------------------------- FAILED - rsyslog new format No matching files were found Less than 1 matches of regex found lab-preventaOne of the following must pass to satisfy this requirement:
------------------------- FAILED - rsyslog old format No matching files were found Less than 1 matches of regex found ------------------------- FAILED - rsyslog new format No matching files were found Less than 1 matches of regex found 4.2.1.6 Ensure remote rsyslog messages are only accepted on designated log hostsInfoRSyslog supports the ability to receive messages from remote hosts, thus acting as a log server. Clients should not receive data from other hosts.Rationale: If a client is configured to also receive data, thus turning it into a server, the client system is acting outside it's operational boundary. SolutionShould there be any active log server configuration found in the auditing section, modify those file and remove the specific lines highlighted by the audit. Ensure none of the following entries are present in any of /etc/rsyslog.conf or /etc/rsyslog.d/*.conf.Old format $ModLoad imtcp $InputTCPServerRun New format module(load='imtcp') input(type='imtcp' port='514') Restart the service: # systemctl restart rsyslog See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaAll of the following must pass to satisfy this requirement:
------------------------- FAILED - Old format ModLoad imtcp The file "/etc/rsyslog.conf" does not contain "^[\s]*\$ModLoad imtcp" ------------------------- FAILED - Old format InputTCPServerRun The file "/etc/rsyslog.conf" does not contain "^[\s]*\$InputTCPServerRun" ------------------------- FAILED - New format module load imtcp The file "/etc/rsyslog.conf" does not contain "^\h*module\(load="imtcp"\)" ------------------------- FAILED - New format input imtcp The file "/etc/rsyslog.conf" does not contain "^\h*input\(type="imtcp" port="514"\)" lab-preventaAll of the following must pass to satisfy this requirement:
------------------------- FAILED - Old format ModLoad imtcp The file "/etc/rsyslog.conf" does not contain "^[\s]*\$ModLoad imtcp" ------------------------- FAILED - Old format InputTCPServerRun The file "/etc/rsyslog.conf" does not contain "^[\s]*\$InputTCPServerRun" ------------------------- FAILED - New format module load imtcp The file "/etc/rsyslog.conf" does not contain "^\h*module\(load="imtcp"\)" ------------------------- FAILED - New format input imtcp The file "/etc/rsyslog.conf" does not contain "^\h*input\(type="imtcp" port="514"\)" 4.2.2.1 Ensure journald is configured to send logs to rsyslogInfoData from journald may be stored in volatile memory or persisted locally on the server. Utilities exist to accept remote export of journald logs, however, use of the rsyslog service provides a consistent means of log collection and export.Notes: This recommendation assumes that recommendation 4.2.1.5, 'Ensure rsyslog is configured to send logs to a remote log host' has been implemented. The main configuration file /etc/systemd/journald.conf is read before any of the custom *.conf files. If there are custom configs present, they override the main configuration parameters As noted in the journald man pages: journald logs may be exported to rsyslog either through the process mentioned here, or through a facility like systemd-journald.service. There are trade-offs involved in each implementation, where ForwardToSyslog will immediately capture all events (and forward to an external log server, if properly configured), but may not capture all boot-up activities. Mechanisms such as systemd-journald.service, on the other hand, will record bootup events, but may delay sending the information to rsyslog, leading to the potential for log manipulation prior to export. Be aware of the limitations of all tools employed to secure a system. Rationale: Storing log data on a remote host protects log integrity from local attacks. If an attacker gains root access on the local system, they could tamper with or remove log data that is stored on the local system. SolutionEdit the /etc/systemd/journald.conf file and add the following line:ForwardToSyslog=yes See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe file "/etc/systemd/journald.conf" does not contain "^[\s]*ForwardToSyslog[\s]*="
lab-preventaThe file "/etc/systemd/journald.conf" does not contain "^[\s]*ForwardToSyslog[\s]*="
4.2.2.2 Ensure journald is configured to compress large log filesInfoThe journald system includes the capability of compressing overly large files to avoid filling up the system with logs or making the logs unmanageably large.Note: The main configuration file /etc/systemd/journald.conf is read before any of the custom *.conf files. If there are custom configs present, they override the main configuration parameters Rationale: Uncompressed large files may unexpectedly fill a filesystem leading to resource unavailability. Compressing logs prior to write can prevent sudden, unexpected filesystem impacts. SolutionEdit the /etc/systemd/journald.conf file and add the following line:Compress=yes See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe file "/etc/systemd/journald.conf" does not contain "^[\s]*Compress[\s]*="
lab-preventaThe file "/etc/systemd/journald.conf" does not contain "^[\s]*Compress[\s]*="
4.2.2.3 Ensure journald is configured to write logfiles to persistent diskInfoData from journald may be stored in volatile memory or persisted locally on the server. Logs in memory will be lost upon a system reboot. By persisting logs to local disk on the server they are protected from loss.Note: The main configuration file /etc/systemd/journald.conf is read before any of the custom *.conf files. If there are custom configs present, they override the main configuration parameters Rationale: Writing log data to disk will provide the ability to forensically reconstruct events which may have impacted the operations or security of a system even after a system crash or reboot. SolutionEdit the /etc/systemd/journald.conf file and add the following line:Storage=persistent See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe file "/etc/systemd/journald.conf" does not contain "^[\s]*Storage[\s]*="
lab-preventaThe file "/etc/systemd/journald.conf" does not contain "^[\s]*Storage[\s]*="
4.2.3 Ensure permissions on all logfiles are configuredInfoLog files stored in /var/log/ contain logged information from many services on the system, or on log hosts others as well.Rationale: It is important to ensure that log files have the correct permissions to ensure that sensitive data is archived and protected. Other/world should not have the ability to view this information. Group should not have the ability to modify this information. SolutionRun the following commands to set permissions on all existing log files:# find /var/log -type f -exec chmod g-wx,o-rwx '{}' + Note: The configuration for your logging software or services may need to also be modified for any logs that had incorrect permissions, otherwise, the permissions may be reverted to the incorrect permissions See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command 'OUTPUT=$(ls -l /var/log); /usr/bin/find /var/log -type f -perm /g+wx,o+rwx -ls | /bin/awk -v awkvar="${OUTPUT}" '{print} END {if (NR == 0) print awkvar "\npass" ; else print "fail"}'' returned :
33835502 4 -rw-r--r-- 1 root root 193 Jul 12 06:51 /var/log/grubby_prune_debug 33954635 20 -rw-r--r-- 1 root root 292000 Oct 24 16:21 /var/log/lastlog 33683787 68 -rw-rw-r-- 1 root utmp 68736 Oct 24 16:02 /var/log/wtmp 34040117 16 -rw-r--r-- 1 root root 15766 Oct 23 17:27 /var/log/tuned/tuned.log 33592532 44 -rw-r--r-- 1 root root 42947 Oct 23 17:27 /var/log/dmesg 33554985 44 -rw-r--r-- 1 root root 42947 Oct 23 16:33 /var/log/dmesg.old fail lab-preventaThe command 'OUTPUT=$(ls -l /var/log); /usr/bin/find /var/log -type f -perm /g+wx,o+rwx -ls | /bin/awk -v awkvar="${OUTPUT}" '{print} END {if (NR == 0) print awkvar "\npass" ; else print "fail"}'' returned :
33835502 4 -rw-r--r-- 1 root root 193 Jul 12 06:51 /var/log/grubby_prune_debug 33954635 20 -rw-r--r-- 1 root root 292000 Oct 24 15:39 /var/log/lastlog 33683787 68 -rw-rw-r-- 1 root utmp 68736 Oct 24 16:02 /var/log/wtmp 34040117 16 -rw-r--r-- 1 root root 15766 Oct 23 17:27 /var/log/tuned/tuned.log 33592532 44 -rw-r--r-- 1 root root 42947 Oct 23 17:27 /var/log/dmesg 33554985 44 -rw-r--r-- 1 root root 42947 Oct 23 16:33 /var/log/dmesg.old fail 5.2.2 Ensure sudo commands use ptyInfosudo can be configured to run only from a pseudo-ptyNote: visudo edits the sudoers file in a safe fashion, analogous to vipw(8). visudo locks the sudoers file against multiple simultaneous edits, provides basic sanity checks, and checks for parse errors. If the sudoers file is currently being edited you will receive a message to try again later. The -f option allows you to tell visudo which file to edit. Rationale: Attackers can run a malicious program using sudo, which would again fork a background process that remains even when the main program has finished executing. This can be mitigated by configuring sudo to run other commands only from a pseudo-pty, whether I/O logging is turned on or not. SolutionEdit the file /etc/sudoers or a file in /etc/sudoers.d/ with visudo or visudo -f <PATH TO FILE> and add the following line:Defaults use_pty See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*Defaults[[:space:]]+([^#]+,[[:space:]]*)?use_pty' /etc/sudoers /etc/sudoers.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail lab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*Defaults[[:space:]]+([^#]+,[[:space:]]*)?use_pty' /etc/sudoers /etc/sudoers.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail 5.2.3 Ensure sudo log file existsInfosudo can use a custom log fileNote: visudo edits the sudoers file in a safe fashion, analogous to vipw(8). visudo locks the sudoers file against multiple simultaneous edits, provides basic sanity checks, and checks for parse errors. If the sudoers file is currently being edited you will receive a message to try again later. The -f option allows you to tell visudo which file to edit. Rationale: A sudo log file simplifies auditing of sudo commands Impact: Editing the sudo configuration incorrectly can cause sudo to stop functioning Solutionedit the file /etc/sudoers or a file in /etc/sudoers.d/ with visudo or visudo -f <PATH TO FILE> and add the following line:Defaults logfile='<PATH TO CUSTOM LOG FILE>' Example: Defaults logfile='/var/log/sudo.log' See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*Defaults[[:space:]]+([^#]+,[[:space:]]*)?logfile=' /etc/sudoers /etc/sudoers.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail lab-preventaThe command '/usr/bin/grep -s -E '^[[:space:]]*Defaults[[:space:]]+([^#]+,[[:space:]]*)?logfile=' /etc/sudoers /etc/sudoers.d/* | /usr/bin/awk '{print} END {if (NR != 0) print "pass" ; else print "fail"}'' returned :
fail 5.3.10 Ensure SSH root login is disabledInfoThe PermitRootLogin parameter specifies if the root user can log in using ssh. The default is no.Rationale: Disallowing root logins over SSH requires system admins to authenticate using their own individual account, then escalating to root via sudo. This in turn limits opportunity for non-repudiation and provides a clear audit trail in the event of a security incident SolutionEdit the /etc/ssh/sshd_config file to set the parameter as follows:PermitRootLogin no Default Value: PermitRootLogin without-password See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sshd -T | /usr/bin/grep -P -i '^[\s]*PermitRootLogin[\s]'' returned :
permitrootlogin yes lab-preventaThe command '/usr/sbin/sshd -T | /usr/bin/grep -P -i '^[\s]*PermitRootLogin[\s]'' returned :
permitrootlogin yes 5.3.14 Ensure only strong MAC algorithms are used - approved MACsInfoThis variable Specifies the available MAC (message authentication code) algorithms. The MAC algorithm is used in protocol version 2 for data integrity protection. Multiple algorithms must be comma-separated.Note: Some organizations may have stricter requirements for approved MACs. Ensure that MACs used are in compliance with site policy. Rationale: MD5 and 96-bit MAC algorithms are considered weak and have been shown to increase exploitability in SSH downgrade attacks. Weak algorithms continue to have a great deal of attention as a weak spot that can be exploited with expanded computing power. An attacker that breaks the algorithm could take advantage of a MiTM position to decrypt the SSH tunnel and capture credentials and information SolutionEdit the /etc/ssh/sshd_config file and add/modify the MACs line to contain a comma separated list of the site approved MACs Example:MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-256 Default Value: MACs umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-sha1-etm@openssh.com See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sshd -T | /usr/bin/grep -P -i '^[\s]*[Mm][Aa][Cc][Ss][\s]+'' returned :
macs umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 lab-preventaThe command '/usr/sbin/sshd -T | /usr/bin/grep -P -i '^[\s]*[Mm][Aa][Cc][Ss][\s]+'' returned :
macs umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 5.3.16 Ensure SSH Idle Timeout Interval is configured - ClientAliveCountMaxInfoThe two options ClientAliveInterval and ClientAliveCountMax control the timeout of ssh sessions.ClientAliveInterval sets a timeout interval in seconds after which if no data has been received from the client, sshd will send a message through the encrypted channel to request a response from the client. The default is 0, indicating that these messages will not be sent to the client. ClientAliveCountMax sets the number of client alive messages which may be sent without sshd receiving any messages back from the client. If this threshold is reached while client alive messages are being sent, sshd will disconnect the client, terminating the session. The default value is 3. The client alive messages are sent through the encrypted channel Setting ClientAliveCountMax to 0 disables connection termination Example: The default value is 3. If ClientAliveInterval is set to 15, and ClientAliveCountMax is left at the default, unresponsive SSH clients will be disconnected after approximately 45 seconds Rationale: Having no timeout value associated with a connection could allow an unauthorized user access to another user's ssh session (e.g. user walks away from their computer and doesn't lock the screen). Setting a timeout value reduces this risk. The recommended ClientAliveInterval setting is no greater than 900 seconds (15 minutes) The recommended ClientAliveCountMax setting is 0 At the 15 minute interval, if the ssh session is inactive, the session will be terminated. Impact: In some cases this setting may cause termination of long-running scripts over SSH or remote automation tools which rely on SSH. In developing the local site policy, the requirements of such scripts should be considered and appropriate ServerAliveInterval and ClientAliveInterval settings should be calculated to insure operational continuity. SolutionEdit the /etc/ssh/sshd_config file to set the parameters according to site policy. This should include ClientAliveInterval between 1 and 900 and ClientAliveCountMax of 0:ClientAliveInterval 900 ClientAliveCountMax 0 Default Value: ClientAliveInterval 0 ClientAliveCountMax 3 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sshd -T | /usr/bin/grep -P -i '^[\s]*ClientAliveCountMax[\s]+'' returned :
clientalivecountmax 3 lab-preventaThe command '/usr/sbin/sshd -T | /usr/bin/grep -P -i '^[\s]*ClientAliveCountMax[\s]+'' returned :
clientalivecountmax 3 5.3.16 Ensure SSH Idle Timeout Interval is configured - ClientAliveIntervalInfoThe two options ClientAliveInterval and ClientAliveCountMax control the timeout of ssh sessions.ClientAliveInterval sets a timeout interval in seconds after which if no data has been received from the client, sshd will send a message through the encrypted channel to request a response from the client. The default is 0, indicating that these messages will not be sent to the client. ClientAliveCountMax sets the number of client alive messages which may be sent without sshd receiving any messages back from the client. If this threshold is reached while client alive messages are being sent, sshd will disconnect the client, terminating the session. The default value is 3. The client alive messages are sent through the encrypted channel Setting ClientAliveCountMax to 0 disables connection termination Example: The default value is 3. If ClientAliveInterval is set to 15, and ClientAliveCountMax is left at the default, unresponsive SSH clients will be disconnected after approximately 45 seconds Rationale: Having no timeout value associated with a connection could allow an unauthorized user access to another user's ssh session (e.g. user walks away from their computer and doesn't lock the screen). Setting a timeout value reduces this risk. The recommended ClientAliveInterval setting is no greater than 900 seconds (15 minutes) The recommended ClientAliveCountMax setting is 0 At the 15 minute interval, if the ssh session is inactive, the session will be terminated. Impact: In some cases this setting may cause termination of long-running scripts over SSH or remote automation tools which rely on SSH. In developing the local site policy, the requirements of such scripts should be considered and appropriate ServerAliveInterval and ClientAliveInterval settings should be calculated to insure operational continuity. SolutionEdit the /etc/ssh/sshd_config file to set the parameters according to site policy. This should include ClientAliveInterval between 1 and 900 and ClientAliveCountMax of 0:ClientAliveInterval 900 ClientAliveCountMax 0 Default Value: ClientAliveInterval 0 ClientAliveCountMax 3 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sshd -T | /usr/bin/grep -P -i '^[\s]*ClientAliveInterval[\s]'' returned :
clientaliveinterval 0 lab-preventaThe command '/usr/sbin/sshd -T | /usr/bin/grep -P -i '^[\s]*ClientAliveInterval[\s]'' returned :
clientaliveinterval 0 5.3.17 Ensure SSH LoginGraceTime is set to one minute or lessInfoThe LoginGraceTime parameter specifies the time allowed for successful authentication to the SSH server. The longer the Grace period is the more open unauthenticated connections can exist. Like other session controls in this session the Grace Period should be limited to appropriate organizational limits to ensure the service is available for needed access.Rationale: Setting the LoginGraceTime parameter to a low number will minimize the risk of successful brute force attacks to the SSH server. It will also limit the number of concurrent unauthenticated connections While the recommended setting is 60 seconds (1 Minute), set the number based on site policy. SolutionEdit the /etc/ssh/sshd_config file to set the parameter as follows:LoginGraceTime 60 Default Value: LoginGraceTime 2m See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sshd -T | /usr/bin/grep -P -i '^[\s]*LoginGraceTime[\s]'' returned :
logingracetime 120 lab-preventaThe command '/usr/sbin/sshd -T | /usr/bin/grep -P -i '^[\s]*LoginGraceTime[\s]'' returned :
logingracetime 120 5.3.18 Ensure SSH warning banner is configuredInfoThe Banner parameter specifies a file whose contents must be sent to the remote user before authentication is permitted. By default, no banner is displayed.Rationale: Banners are used to warn connecting users of the particular site's policy regarding connection. Presenting a warning message prior to the normal user login may assist the prosecution of trespassers on the computer system. SolutionEdit the /etc/ssh/sshd_config file to set the parameter as follows:Banner /etc/issue.net See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sshd -T | /usr/bin/grep -P -i '^[\s]*Banner[\s]'' returned :
banner none lab-preventaThe command '/usr/sbin/sshd -T | /usr/bin/grep -P -i '^[\s]*Banner[\s]'' returned :
banner none 5.3.21 Ensure SSH MaxStartups is configuredInfoThe MaxStartups parameter specifies the maximum number of concurrent unauthenticated connections to the SSH daemon.Rationale: To protect a system from denial of service due to a large number of pending authentication connection attempts, use the rate limiting function of MaxStartups to protect availability of sshd logins and prevent overwhelming the daemon. SolutionEdit the /etc/ssh/sshd_config file to set the parameter as follows:maxstartups 10:30:60 Default Value: MaxStartups 10:30:100 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sshd -T | /usr/bin/grep -P -i '^[\s]*[Mm]ax[Ss]tartups[\s]'' returned :
maxstartups 10:30:100 lab-preventaThe command '/usr/sbin/sshd -T | /usr/bin/grep -P -i '^[\s]*[Mm]ax[Ss]tartups[\s]'' returned :
maxstartups 10:30:100 5.3.4 Ensure SSH access is limitedInfoThere are several options available to limit which users and group can access the system via SSH. It is recommended that at least one of the following options be leveraged:AllowUsers: The AllowUsers variable gives the system administrator the option of allowing specific users to ssh into the system. The list consists of space separated user names. Numeric user IDs are not recognized with this variable. If a system administrator wants to restrict user access further by only allowing the allowed users to log in from a particular host, the entry can be specified in the form of user@host. AllowGroups: The AllowGroups variable gives the system administrator the option of allowing specific groups of users to ssh into the system. The list consists of space separated group names. Numeric group IDs are not recognized with this variable. DenyUsers: The DenyUsers variable gives the system administrator the option of denying specific users to ssh into the system. The list consists of space separated user names. Numeric user IDs are not recognized with this variable. If a system administrator wants to restrict user access further by specifically denying a user's access from a particular host, the entry can be specified in the form of user@host. DenyGroups: The DenyGroups variable gives the system administrator the option of denying specific groups of users to ssh into the system. The list consists of space separated group names. Numeric group IDs are not recognized with this variable. Rationale: Restricting which users can remotely access the system via SSH will help ensure that only authorized users access the system. SolutionEdit the /etc/ssh/sshd_config file to set one or more of the parameter as follows:AllowUsers <userlist> OR AllowGroups <grouplist> OR DenyUsers <userlist> OR DenyGroups <grouplist> Default Value: None See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sshd -T | /usr/bin/grep -P -i '^[\s]*(allow|deny)(users|groups)[\s]+'' did not return any result
lab-preventaThe command '/usr/sbin/sshd -T | /usr/bin/grep -P -i '^[\s]*(allow|deny)(users|groups)[\s]+'' did not return any result
5.3.6 Ensure SSH X11 forwarding is disabledInfoThe X11Forwarding parameter provides the ability to tunnel X11 traffic through an existing SSH shell session to enable remote graphic connections.Rationale: Disable X11 forwarding unless there is an operational requirement to use X11 applications directly. There is a small risk that the remote X11 servers of users who are logged in via SSH with X11 forwarding could be compromised by other users on the X11 server. Note that even if X11 forwarding is disabled, users can always install their own forwarders. Impact: X11 programs on the server will not be able to be forwarded to a ssh-client display. SolutionEdit the /etc/ssh/sshd_config file to set the parameter as follows:X11Forwarding no Default Value: X11Forwarding yes See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sshd -T | /usr/bin/grep x11forwarding' returned :
x11forwarding yes 5.3.7 Ensure SSH MaxAuthTries is set to 4 or lessInfoThe MaxAuthTries parameter specifies the maximum number of authentication attempts permitted per connection. When the login failure count reaches half the number, error messages will be written to the syslog file detailing the login failure.Rationale: Setting the MaxAuthTries parameter to a low number will minimize the risk of successful brute force attacks to the SSH server. While the recommended setting is 4, set the number based on site policy. SolutionEdit the /etc/ssh/sshd_config file to set the parameter as follows:MaxAuthTries 4 Default Value: MaxAuthTries 6 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sshd -T | /usr/bin/grep -P -i '^[\s]*MaxAuthTries[\s]'' returned :
maxauthtries 6 lab-preventaThe command '/usr/sbin/sshd -T | /usr/bin/grep -P -i '^[\s]*MaxAuthTries[\s]'' returned :
maxauthtries 6 5.4.1 Ensure password creation requirements are configured - dcreditInfoThe pam_pwquality.so module checks the strength of passwords. It performs checks such as making sure a password is not a dictionary word, it is a certain length, contains a mix of characters (e.g. alphabet, numeric, other) and more. The following are definitions of the pam_pwquality.so options.The following options are set in the /etc/security/pwquality.conf file: Password Length: minlen = 14 - password must be 14 characters or more Password complexity: minclass = 4 - The minimum number of required classes of characters for the new password (digits, uppercase, lowercase, others) OR dcredit = -1 - provide at least one digit ucredit = -1 - provide at least one uppercase character ocredit = -1 - provide at least one special character lcredit = -1 - provide at least one lowercase character The following is set in the /etc/pam.d/password-auth and /etc/pam.d/system-auth files try_first_pass - retrieve the password from a previous stacked PAM module. If not available, then prompt the user for a password. retry=3 - Allow 3 tries before sending back a failure. The settings shown above are one possible policy. Alter these values to conform to your own organization's password policies. Notes: Settings in /etc/security/pwquality.conf must use spaces around the = symbol. Additional modules options may be set in the /etc/pam.d/password-auth and /etc/pam.d/system-auth files Rationale: Strong passwords and limited attempts before locking an account protect systems from being hacked through brute force methods. SolutionEdit the file /etc/security/pwquality.conf and add or modify the following line for password length to conform to site policyminlen = 14 Edit the file /etc/security/pwquality.conf and add or modify the following line for password complexity to conform to site policy minclass = 4 OR dcredit = -1 ucredit = -1 ocredit = -1 lcredit = -1 Edit the /etc/pam.d/password-auth and /etc/pam.d/system-auth files to include the appropriate options for pam_pwquality.so and to conform to site policy: password requisite pam_pwquality.so try_first_pass retry=3 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe file "/etc/security/pwquality.conf" does not contain "^[\s]*dcredit[\s]*="
lab-preventaThe file "/etc/security/pwquality.conf" does not contain "^[\s]*dcredit[\s]*="
5.4.1 Ensure password creation requirements are configured - lcreditInfoThe pam_pwquality.so module checks the strength of passwords. It performs checks such as making sure a password is not a dictionary word, it is a certain length, contains a mix of characters (e.g. alphabet, numeric, other) and more. The following are definitions of the pam_pwquality.so options.The following options are set in the /etc/security/pwquality.conf file: Password Length: minlen = 14 - password must be 14 characters or more Password complexity: minclass = 4 - The minimum number of required classes of characters for the new password (digits, uppercase, lowercase, others) OR dcredit = -1 - provide at least one digit ucredit = -1 - provide at least one uppercase character ocredit = -1 - provide at least one special character lcredit = -1 - provide at least one lowercase character The following is set in the /etc/pam.d/password-auth and /etc/pam.d/system-auth files try_first_pass - retrieve the password from a previous stacked PAM module. If not available, then prompt the user for a password. retry=3 - Allow 3 tries before sending back a failure. The settings shown above are one possible policy. Alter these values to conform to your own organization's password policies. Notes: Settings in /etc/security/pwquality.conf must use spaces around the = symbol. Additional modules options may be set in the /etc/pam.d/password-auth and /etc/pam.d/system-auth files Rationale: Strong passwords and limited attempts before locking an account protect systems from being hacked through brute force methods. SolutionEdit the file /etc/security/pwquality.conf and add or modify the following line for password length to conform to site policyminlen = 14 Edit the file /etc/security/pwquality.conf and add or modify the following line for password complexity to conform to site policy minclass = 4 OR dcredit = -1 ucredit = -1 ocredit = -1 lcredit = -1 Edit the /etc/pam.d/password-auth and /etc/pam.d/system-auth files to include the appropriate options for pam_pwquality.so and to conform to site policy: password requisite pam_pwquality.so try_first_pass retry=3 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe file "/etc/security/pwquality.conf" does not contain "^[\s]*lcredit[\s]*="
lab-preventaThe file "/etc/security/pwquality.conf" does not contain "^[\s]*lcredit[\s]*="
5.4.1 Ensure password creation requirements are configured - minlenInfoThe pam_pwquality.so module checks the strength of passwords. It performs checks such as making sure a password is not a dictionary word, it is a certain length, contains a mix of characters (e.g. alphabet, numeric, other) and more. The following are definitions of the pam_pwquality.so options.The following options are set in the /etc/security/pwquality.conf file: Password Length: minlen = 14 - password must be 14 characters or more Password complexity: minclass = 4 - The minimum number of required classes of characters for the new password (digits, uppercase, lowercase, others) OR dcredit = -1 - provide at least one digit ucredit = -1 - provide at least one uppercase character ocredit = -1 - provide at least one special character lcredit = -1 - provide at least one lowercase character The following is set in the /etc/pam.d/password-auth and /etc/pam.d/system-auth files try_first_pass - retrieve the password from a previous stacked PAM module. If not available, then prompt the user for a password. retry=3 - Allow 3 tries before sending back a failure. The settings shown above are one possible policy. Alter these values to conform to your own organization's password policies. Notes: Settings in /etc/security/pwquality.conf must use spaces around the = symbol. Additional modules options may be set in the /etc/pam.d/password-auth and /etc/pam.d/system-auth files Rationale: Strong passwords and limited attempts before locking an account protect systems from being hacked through brute force methods. SolutionEdit the file /etc/security/pwquality.conf and add or modify the following line for password length to conform to site policyminlen = 14 Edit the file /etc/security/pwquality.conf and add or modify the following line for password complexity to conform to site policy minclass = 4 OR dcredit = -1 ucredit = -1 ocredit = -1 lcredit = -1 Edit the /etc/pam.d/password-auth and /etc/pam.d/system-auth files to include the appropriate options for pam_pwquality.so and to conform to site policy: password requisite pam_pwquality.so try_first_pass retry=3 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe file "/etc/security/pwquality.conf" does not contain "^[\s]*minlen[\s]*="
lab-preventaThe file "/etc/security/pwquality.conf" does not contain "^[\s]*minlen[\s]*="
5.4.1 Ensure password creation requirements are configured - ocreditInfoThe pam_pwquality.so module checks the strength of passwords. It performs checks such as making sure a password is not a dictionary word, it is a certain length, contains a mix of characters (e.g. alphabet, numeric, other) and more. The following are definitions of the pam_pwquality.so options.The following options are set in the /etc/security/pwquality.conf file: Password Length: minlen = 14 - password must be 14 characters or more Password complexity: minclass = 4 - The minimum number of required classes of characters for the new password (digits, uppercase, lowercase, others) OR dcredit = -1 - provide at least one digit ucredit = -1 - provide at least one uppercase character ocredit = -1 - provide at least one special character lcredit = -1 - provide at least one lowercase character The following is set in the /etc/pam.d/password-auth and /etc/pam.d/system-auth files try_first_pass - retrieve the password from a previous stacked PAM module. If not available, then prompt the user for a password. retry=3 - Allow 3 tries before sending back a failure. The settings shown above are one possible policy. Alter these values to conform to your own organization's password policies. Notes: Settings in /etc/security/pwquality.conf must use spaces around the = symbol. Additional modules options may be set in the /etc/pam.d/password-auth and /etc/pam.d/system-auth files Rationale: Strong passwords and limited attempts before locking an account protect systems from being hacked through brute force methods. SolutionEdit the file /etc/security/pwquality.conf and add or modify the following line for password length to conform to site policyminlen = 14 Edit the file /etc/security/pwquality.conf and add or modify the following line for password complexity to conform to site policy minclass = 4 OR dcredit = -1 ucredit = -1 ocredit = -1 lcredit = -1 Edit the /etc/pam.d/password-auth and /etc/pam.d/system-auth files to include the appropriate options for pam_pwquality.so and to conform to site policy: password requisite pam_pwquality.so try_first_pass retry=3 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe file "/etc/security/pwquality.conf" does not contain "^[\s]*ocredit[\s]*="
lab-preventaThe file "/etc/security/pwquality.conf" does not contain "^[\s]*ocredit[\s]*="
5.4.1 Ensure password creation requirements are configured - ucreditInfoThe pam_pwquality.so module checks the strength of passwords. It performs checks such as making sure a password is not a dictionary word, it is a certain length, contains a mix of characters (e.g. alphabet, numeric, other) and more. The following are definitions of the pam_pwquality.so options.The following options are set in the /etc/security/pwquality.conf file: Password Length: minlen = 14 - password must be 14 characters or more Password complexity: minclass = 4 - The minimum number of required classes of characters for the new password (digits, uppercase, lowercase, others) OR dcredit = -1 - provide at least one digit ucredit = -1 - provide at least one uppercase character ocredit = -1 - provide at least one special character lcredit = -1 - provide at least one lowercase character The following is set in the /etc/pam.d/password-auth and /etc/pam.d/system-auth files try_first_pass - retrieve the password from a previous stacked PAM module. If not available, then prompt the user for a password. retry=3 - Allow 3 tries before sending back a failure. The settings shown above are one possible policy. Alter these values to conform to your own organization's password policies. Notes: Settings in /etc/security/pwquality.conf must use spaces around the = symbol. Additional modules options may be set in the /etc/pam.d/password-auth and /etc/pam.d/system-auth files Rationale: Strong passwords and limited attempts before locking an account protect systems from being hacked through brute force methods. SolutionEdit the file /etc/security/pwquality.conf and add or modify the following line for password length to conform to site policyminlen = 14 Edit the file /etc/security/pwquality.conf and add or modify the following line for password complexity to conform to site policy minclass = 4 OR dcredit = -1 ucredit = -1 ocredit = -1 lcredit = -1 Edit the /etc/pam.d/password-auth and /etc/pam.d/system-auth files to include the appropriate options for pam_pwquality.so and to conform to site policy: password requisite pam_pwquality.so try_first_pass retry=3 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe file "/etc/security/pwquality.conf" does not contain "^[\s]*ucredit[\s]*="
lab-preventaThe file "/etc/security/pwquality.conf" does not contain "^[\s]*ucredit[\s]*="
5.4.2 Ensure lockout for failed password attempts is configured - password-authInfoLock out users after n unsuccessful consecutive login attempts.These settings are commonly configured with the pam_faillock.so module. Some environments may continue using the pam_tally2.so module, where this older method may simplify automation in mixed environments. Set the lockout number in deny= to the policy in effect at your site. unlock_time=_n_ is the number of seconds the account remains locked after the number of attempts configured in deny=_n_ has been met. Notes: Additional module options may be set, recommendation only covers those listed here. When modifying authentication configuration using the authconfig utility, the system-auth and password-auth files are overwritten with the settings from the authconfig utility. This can be avoided by creating symbolic links in place of the configuration files, which authconfig recognizes and does not overwrite. These symbolic links are the default for Fedora 19 derived distributions. Use of the 'audit' keyword may log credentials in the case of user error during authentication. This risk should be evaluated in the context of the site policies of your organization. If a user has been locked out because they have reached the maximum consecutive failure count defined by deny= in the pam_faillock.so or the pam_tally2.so module, the user can be unlocked by issuing following commands. This command sets the failed count to 0, effectively unlocking the user. If pam_faillock.so is used: # faillock --user <username> --reset If pam_tally2.so is used: # pam_tally2 -u <username> --reset Rationale: Locking out user IDs after n unsuccessful consecutive login attempts mitigates brute force password attacks against your systems. SolutionEdit the files /etc/pam.d/system-auth and /etc/pam.d/password-auth and add the following lines:Modify the deny= and unlock_time= parameters to conform to local site policy, Not to be greater than deny=5 To use pam_faillock.so module, add the following lines to the auth section: auth required pam_faillock.so preauth silent audit deny=5 unlock_time=900 auth [default=die] pam_faillock.so authfail audit deny=5 unlock_time=900 The auth sections should look similar to the following example: Note: The ordering on the lines in the auth section is important. The preauth line needs to below the line auth required pam_env.so and above all password validation lines. The authfail line needs to be after all password validation lines such as pam_sss.so. Incorrect order can cause you to be locked out of the system Example: auth required pam_env.so auth required pam_faillock.so preauth silent audit deny=5 unlock_time=900 # <- Under 'auth required pam_env.so' auth sufficient pam_unix.so nullok try_first_pass auth [default=die] pam_faillock.so authfail audit deny=5 unlock_time=900 # <- Last auth line before 'auth requisite pam_succeed_if.so' auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth required pam_deny.so Add the following line to the account section: account required pam_faillock.so Example: account required pam_faillock.so account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_pam_succeed_if.so uid < 1000 quiet account required pam_permit.so OR To use the pam_tally2.so module, add the following line to the auth section: auth required pam_tally2.so deny=5 onerr=fail unlock_time=900 The auth sections should look similar to the following example: Note: The ordering on the lines in the auth section is important. the additional line needs to below the line auth required pam_env.so and above all password validation lines. Example: auth required pam_env.so auth required pam_tally2.so deny=5 onerr=fail unlock_time=900 # <- Under 'auth required pam_env.so' auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth required pam_deny.so Add the following line to the account section: account required pam_tally2.so Example: account required pam_tally2.so account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_pam_succeed_if.so uid < 1000 quiet account required pam_permit.so See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command 'linelist=('^[\s]*account[\s]+required[\s]+pam_tally2\.so$' '^[\s]*auth[\s]+required[\s]+pam_tally2\.so[\s]+(?=.*deny[\s]*=[\s]*[1-5])(?=.*onerr=fail)(?=.*unlock_time[\s]*=[\s]*(9[0-9][0-9]|d{4,}))'); for line in ${linelist[@]}; do grep -P $line /etc/pam.d/password-auth; done | awk '{ print } END { if (NR==2) print "pass"; else print "fail"}'' returned :
fail lab-preventaThe command 'linelist=('^[\s]*account[\s]+required[\s]+pam_tally2\.so$' '^[\s]*auth[\s]+required[\s]+pam_tally2\.so[\s]+(?=.*deny[\s]*=[\s]*[1-5])(?=.*onerr=fail)(?=.*unlock_time[\s]*=[\s]*(9[0-9][0-9]|d{4,}))'); for line in ${linelist[@]}; do grep -P $line /etc/pam.d/password-auth; done | awk '{ print } END { if (NR==2) print "pass"; else print "fail"}'' returned :
fail 5.4.2 Ensure lockout for failed password attempts is configured - system-authInfoLock out users after n unsuccessful consecutive login attempts.These settings are commonly configured with the pam_faillock.so module. Some environments may continue using the pam_tally2.so module, where this older method may simplify automation in mixed environments. Set the lockout number in deny= to the policy in effect at your site. unlock_time=_n_ is the number of seconds the account remains locked after the number of attempts configured in deny=_n_ has been met. Notes: Additional module options may be set, recommendation only covers those listed here. When modifying authentication configuration using the authconfig utility, the system-auth and password-auth files are overwritten with the settings from the authconfig utility. This can be avoided by creating symbolic links in place of the configuration files, which authconfig recognizes and does not overwrite. These symbolic links are the default for Fedora 19 derived distributions. Use of the 'audit' keyword may log credentials in the case of user error during authentication. This risk should be evaluated in the context of the site policies of your organization. If a user has been locked out because they have reached the maximum consecutive failure count defined by deny= in the pam_faillock.so or the pam_tally2.so module, the user can be unlocked by issuing following commands. This command sets the failed count to 0, effectively unlocking the user. If pam_faillock.so is used: # faillock --user <username> --reset If pam_tally2.so is used: # pam_tally2 -u <username> --reset Rationale: Locking out user IDs after n unsuccessful consecutive login attempts mitigates brute force password attacks against your systems. SolutionEdit the files /etc/pam.d/system-auth and /etc/pam.d/password-auth and add the following lines:Modify the deny= and unlock_time= parameters to conform to local site policy, Not to be greater than deny=5 To use pam_faillock.so module, add the following lines to the auth section: auth required pam_faillock.so preauth silent audit deny=5 unlock_time=900 auth [default=die] pam_faillock.so authfail audit deny=5 unlock_time=900 The auth sections should look similar to the following example: Note: The ordering on the lines in the auth section is important. The preauth line needs to below the line auth required pam_env.so and above all password validation lines. The authfail line needs to be after all password validation lines such as pam_sss.so. Incorrect order can cause you to be locked out of the system Example: auth required pam_env.so auth required pam_faillock.so preauth silent audit deny=5 unlock_time=900 # <- Under 'auth required pam_env.so' auth sufficient pam_unix.so nullok try_first_pass auth [default=die] pam_faillock.so authfail audit deny=5 unlock_time=900 # <- Last auth line before 'auth requisite pam_succeed_if.so' auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth required pam_deny.so Add the following line to the account section: account required pam_faillock.so Example: account required pam_faillock.so account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_pam_succeed_if.so uid < 1000 quiet account required pam_permit.so OR To use the pam_tally2.so module, add the following line to the auth section: auth required pam_tally2.so deny=5 onerr=fail unlock_time=900 The auth sections should look similar to the following example: Note: The ordering on the lines in the auth section is important. the additional line needs to below the line auth required pam_env.so and above all password validation lines. Example: auth required pam_env.so auth required pam_tally2.so deny=5 onerr=fail unlock_time=900 # <- Under 'auth required pam_env.so' auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth required pam_deny.so Add the following line to the account section: account required pam_tally2.so Example: account required pam_tally2.so account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_pam_succeed_if.so uid < 1000 quiet account required pam_permit.so See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command 'linelist=('^[\s]*account[\s]+required[\s]+pam_tally2\.so$' '^[\s]*auth[\s]+required[\s]+pam_tally2\.so[\s]+(?=.*deny[\s]*=[\s]*[1-5])(?=.*onerr=fail)(?=.*unlock_time[\s]*=[\s]*(9[0-9][0-9]|d{4,}))'); for line in ${linelist[@]}; do grep -P $line /etc/pam.d/system-auth; done | awk '{ print } END { if (NR==2) print "pass"; else print "fail"}'' returned :
fail lab-preventaThe command 'linelist=('^[\s]*account[\s]+required[\s]+pam_tally2\.so$' '^[\s]*auth[\s]+required[\s]+pam_tally2\.so[\s]+(?=.*deny[\s]*=[\s]*[1-5])(?=.*onerr=fail)(?=.*unlock_time[\s]*=[\s]*(9[0-9][0-9]|d{4,}))'); for line in ${linelist[@]}; do grep -P $line /etc/pam.d/system-auth; done | awk '{ print } END { if (NR==2) print "pass"; else print "fail"}'' returned :
fail 5.4.4 Ensure password reuse is limitedInfoThe /etc/security/opasswd file stores the users' old passwords and can be checked to ensure that users are not recycling recent passwords.Note: Additional module options may be set, recommendation only covers those listed here. Rationale: Forcing users not to reuse their past 5 passwords make it less likely that an attacker will be able to guess the password. SolutionEdit both the /etc/pam.d/password-auth and /etc/pam.d/system-auth files to include the remember option and conform to site policy as shown:Note: Add or modify the line containing the pam_pwhistory.so after the first occurrence of password requisite: password required pam_pwhistory.so remember=5 Example: (Second line is modified) password requisite pam_pwquality.so try_first_pass local_users_only authtok_type= password required pam_pwhistory.so use_authtok remember=5 retry=3 password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password required pam_deny.so Additional Information: This setting only applies to local accounts. This option is configured with the remember=n module option in /etc/pam.d/system-auth and /etc/pam.d/password-auth This option can be set with either one of the two following modules: pam_pwhistory.so - This is the newer recommended method included in the remediation section. pam_unix.so - This is the older method, and is included in the audit to account for legacy configurations. See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/grep -P '^\s*password\s+(sufficient|requisite|required)\s+pam_unix\.so\s+([^#]+\s+)*remember=([5-9]|[1-9][0-9]+)\b' /etc/pam.d/system-auth /etc/pam.d/password-auth | /usr/bin/awk '{print} END {if (NR == 2) print "pass" ; else print "fail"}'' returned :
fail lab-preventaThe command '/usr/bin/grep -P '^\s*password\s+(sufficient|requisite|required)\s+pam_unix\.so\s+([^#]+\s+)*remember=([5-9]|[1-9][0-9]+)\b' /etc/pam.d/system-auth /etc/pam.d/password-auth | /usr/bin/awk '{print} END {if (NR == 2) print "pass" ; else print "fail"}'' returned :
fail 5.5.1.1 Ensure password expiration is 365 days or less - login.defsInfoThe PASS_MAX_DAYS parameter in /etc/login.defs allows an administrator to force passwords to expire once they reach a defined age. It is recommended that the PASS_MAX_DAYS parameter be set to less than or equal to 365 days.Notes: A value of -1 will disable password expiration. The password expiration must be greater than the minimum days between password changes or users will be unable to change their password. Rationale: The window of opportunity for an attacker to leverage compromised credentials via a brute force attack, using already compromised credentials, or gaining the credentials by other means, can be limited by the age of the password. Therefore, reducing the maximum age of a password can also reduce an attacker's window of opportunity. Requiring passwords to be changed helps to mitigate the risk posed by the poor security practice of passwords being used for multiple accounts, and poorly implemented off-boarding and change of responsibility policies. This should not be considered a replacement for proper implementation of these policies and practices. Note: If it is believed that a user's password may have been compromised, the user's account should be locked immediately. Local policy should be followed to ensure the secure update of their password. SolutionSet the PASS_MAX_DAYS parameter to conform to site policy in /etc/login.defs :PASS_MAX_DAYS 365 Modify user parameters for all users with a password set to match: # chage --maxdays 365 <user> See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaNon-compliant file(s):
/etc/login.defs - regex '^[\s]*PASS_MAX_DAYS[\s]' found - expect '^[\s]*PASS_MAX_DAYS[\s]+([1-9]|[1-9][0-9]|[1-2][0-9][0-9]|3[0-5][0-9]|36[0-5])[\s]*$' not found in the following lines: 25: PASS_MAX_DAYS 99999 lab-preventaNon-compliant file(s):
/etc/login.defs - regex '^[\s]*PASS_MAX_DAYS[\s]' found - expect '^[\s]*PASS_MAX_DAYS[\s]+([1-9]|[1-9][0-9]|[1-2][0-9][0-9]|3[0-5][0-9]|36[0-5])[\s]*$' not found in the following lines: 25: PASS_MAX_DAYS 99999 5.5.1.1 Ensure password expiration is 365 days or less - usersInfoThe PASS_MAX_DAYS parameter in /etc/login.defs allows an administrator to force passwords to expire once they reach a defined age. It is recommended that the PASS_MAX_DAYS parameter be set to less than or equal to 365 days.Notes: A value of -1 will disable password expiration. The password expiration must be greater than the minimum days between password changes or users will be unable to change their password. Rationale: The window of opportunity for an attacker to leverage compromised credentials via a brute force attack, using already compromised credentials, or gaining the credentials by other means, can be limited by the age of the password. Therefore, reducing the maximum age of a password can also reduce an attacker's window of opportunity. Requiring passwords to be changed helps to mitigate the risk posed by the poor security practice of passwords being used for multiple accounts, and poorly implemented off-boarding and change of responsibility policies. This should not be considered a replacement for proper implementation of these policies and practices. Note: If it is believed that a user's password may have been compromised, the user's account should be locked immediately. Local policy should be followed to ensure the secure update of their password. SolutionSet the PASS_MAX_DAYS parameter to conform to site policy in /etc/login.defs :PASS_MAX_DAYS 365 Modify user parameters for all users with a password set to match: # chage --maxdays 365 <user> See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaNon-compliant file(s):
/etc/shadow - regex '^[^:]+:[^!*]' found - expect '^([^:]*:){4}([1-9]|[1-9][0-9]|[1-2][0-9][0-9]|3[0-5][0-9]|36[0-5]):' not found in the following lines: 1: root:$6$VGyBibZp.jE4gn93$w72KJba0CBCKz.5mcjokPGnbgio.oq.GdALX8UniF.HppYLQqsfULaoIK0s4U3H2rz/xEwTXdIN7aJwvnxbG41::0:99999:7::: 20: admin:$6$/WfmeNEcZ8ESDkhI$AI3AqWU1ZPpzcd5qJL/rj6LN1FDyb6olJctlOOiyRZf8Ss/pJxLvxy0V95j8b/w9qhDP/gnPk.curbLouYUGw/::0:99999:7::: lab-preventaNon-compliant file(s):
/etc/shadow - regex '^[^:]+:[^!*]' found - expect '^([^:]*:){4}([1-9]|[1-9][0-9]|[1-2][0-9][0-9]|3[0-5][0-9]|36[0-5]):' not found in the following lines: 1: root:$6$VGyBibZp.jE4gn93$w72KJba0CBCKz.5mcjokPGnbgio.oq.GdALX8UniF.HppYLQqsfULaoIK0s4U3H2rz/xEwTXdIN7aJwvnxbG41::0:99999:7::: 20: admin:$6$/WfmeNEcZ8ESDkhI$AI3AqWU1ZPpzcd5qJL/rj6LN1FDyb6olJctlOOiyRZf8Ss/pJxLvxy0V95j8b/w9qhDP/gnPk.curbLouYUGw/::0:99999:7::: 5.5.1.2 Ensure minimum days between password changes is configured - /etc/login.defsInfoThe PASS_MIN_DAYS parameter in /etc/login.defs allows an administrator to prevent users from changing their password until a minimum number of days have passed since the last time the user changed their password. It is recommended that PASS_MIN_DAYS parameter be set to 1 or more days.Rationale: By restricting the frequency of password changes, an administrator can prevent users from repeatedly changing their password in an attempt to circumvent password reuse controls. SolutionSet the PASS_MIN_DAYS parameter to 1 in /etc/login.defs :PASS_MIN_DAYS 1 Modify user parameters for all users with a password set to match: # chage --mindays 1 <user> See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaNon-compliant file(s):
/etc/login.defs - regex '^[\s]*PASS_MIN_DAYS[\s]+' found - expect 'PASS_MIN_DAYS[\s]+[1-9][0-9]*[\s]*$' not found in the following lines: 26: PASS_MIN_DAYS 0 lab-preventaNon-compliant file(s):
/etc/login.defs - regex '^[\s]*PASS_MIN_DAYS[\s]+' found - expect 'PASS_MIN_DAYS[\s]+[1-9][0-9]*[\s]*$' not found in the following lines: 26: PASS_MIN_DAYS 0 5.5.1.2 Ensure minimum days between password changes is configured - /etc/shadowInfoThe PASS_MIN_DAYS parameter in /etc/login.defs allows an administrator to prevent users from changing their password until a minimum number of days have passed since the last time the user changed their password. It is recommended that PASS_MIN_DAYS parameter be set to 1 or more days.Rationale: By restricting the frequency of password changes, an administrator can prevent users from repeatedly changing their password in an attempt to circumvent password reuse controls. SolutionSet the PASS_MIN_DAYS parameter to 1 in /etc/login.defs :PASS_MIN_DAYS 1 Modify user parameters for all users with a password set to match: # chage --mindays 1 <user> See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaNon-compliant file(s):
/etc/shadow - regex '^[^:]+:[^!*]' found - expect '^([^:]*:){3}[1-9][0-9]*:' not found in the following lines: 1: root:$6$VGyBibZp.jE4gn93$w72KJba0CBCKz.5mcjokPGnbgio.oq.GdALX8UniF.HppYLQqsfULaoIK0s4U3H2rz/xEwTXdIN7aJwvnxbG41::0:99999:7::: 20: admin:$6$/WfmeNEcZ8ESDkhI$AI3AqWU1ZPpzcd5qJL/rj6LN1FDyb6olJctlOOiyRZf8Ss/pJxLvxy0V95j8b/w9qhDP/gnPk.curbLouYUGw/::0:99999:7::: lab-preventaNon-compliant file(s):
/etc/shadow - regex '^[^:]+:[^!*]' found - expect '^([^:]*:){3}[1-9][0-9]*:' not found in the following lines: 1: root:$6$VGyBibZp.jE4gn93$w72KJba0CBCKz.5mcjokPGnbgio.oq.GdALX8UniF.HppYLQqsfULaoIK0s4U3H2rz/xEwTXdIN7aJwvnxbG41::0:99999:7::: 20: admin:$6$/WfmeNEcZ8ESDkhI$AI3AqWU1ZPpzcd5qJL/rj6LN1FDyb6olJctlOOiyRZf8Ss/pJxLvxy0V95j8b/w9qhDP/gnPk.curbLouYUGw/::0:99999:7::: 5.5.1.4 Ensure inactive password lock is 30 days or less - /etc/default/useraddInfoUser accounts that have been inactive for over a given period of time can be automatically disabled. It is recommended that accounts that are inactive for 30 days after password expiration be disabled.Note: A value of -1 would disable this setting. Rationale: Inactive accounts pose a threat to system security since the users are not logging in to notice failed login attempts or other anomalies. SolutionRun the following command to set the default password inactivity period to 30 days:# useradd -D -f 30 Modify user parameters for all users with a password set to match: # chage --inactive 30 <user> See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaNon-compliant file(s):
/etc/default/useradd - regex '^[\s]*INACTIVE[\s]*=[\s]*' found - expect '^[\s]*INACTIVE[\s]*=[\s]*(30|[1-2][0-9]|[1-9])$[\s]*$' not found in the following lines: 4: INACTIVE=-1 lab-preventaNon-compliant file(s):
/etc/default/useradd - regex '^[\s]*INACTIVE[\s]*=[\s]*' found - expect '^[\s]*INACTIVE[\s]*=[\s]*(30|[1-2][0-9]|[1-9])$[\s]*$' not found in the following lines: 4: INACTIVE=-1 5.5.1.4 Ensure inactive password lock is 30 days or less - usersInfoUser accounts that have been inactive for over a given period of time can be automatically disabled. It is recommended that accounts that are inactive for 30 days after password expiration be disabled.Note: A value of -1 would disable this setting. Rationale: Inactive accounts pose a threat to system security since the users are not logging in to notice failed login attempts or other anomalies. SolutionRun the following command to set the default password inactivity period to 30 days:# useradd -D -f 30 Modify user parameters for all users with a password set to match: # chage --inactive 30 <user> See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaNon-compliant file(s):
/etc/shadow - regex '^[^:]+:[^!*]' found - expect '^([^:]*:){6}(30|[1-2][0-9]|[1-9]):' not found in the following lines: 1: root:$6$VGyBibZp.jE4gn93$w72KJba0CBCKz.5mcjokPGnbgio.oq.GdALX8UniF.HppYLQqsfULaoIK0s4U3H2rz/xEwTXdIN7aJwvnxbG41::0:99999:7::: 20: admin:$6$/WfmeNEcZ8ESDkhI$AI3AqWU1ZPpzcd5qJL/rj6LN1FDyb6olJctlOOiyRZf8Ss/pJxLvxy0V95j8b/w9qhDP/gnPk.curbLouYUGw/::0:99999:7::: lab-preventaNon-compliant file(s):
/etc/shadow - regex '^[^:]+:[^!*]' found - expect '^([^:]*:){6}(30|[1-2][0-9]|[1-9]):' not found in the following lines: 1: root:$6$VGyBibZp.jE4gn93$w72KJba0CBCKz.5mcjokPGnbgio.oq.GdALX8UniF.HppYLQqsfULaoIK0s4U3H2rz/xEwTXdIN7aJwvnxbG41::0:99999:7::: 20: admin:$6$/WfmeNEcZ8ESDkhI$AI3AqWU1ZPpzcd5qJL/rj6LN1FDyb6olJctlOOiyRZf8Ss/pJxLvxy0V95j8b/w9qhDP/gnPk.curbLouYUGw/::0:99999:7::: 5.5.4 Ensure default user shell timeout is configuredInfoTMOUT is an environmental setting that determines the timeout of a shell in seconds.TMOUT=n - Sets the shell timeout to n seconds. A setting of TMOUT=0 disables timeout. readonly TMOUT- Sets the TMOUT environmental variable as readonly, preventing unwanted modification during run-time. export TMOUT - exports the TMOUT variable System Wide Shell Configuration Files: /etc/profile - used to set system wide environmental variables on users shells. The variables are sometimes the same ones that are in the .bash_profile, however this file is used to set an initial PATH or PS1 for all shell users of the system. is only executed for interactive login shells, or shells executed with the --login parameter. /etc/profile.d - /etc/profile will execute the scripts within /etc/profile.d/*.sh. It is recommended to place your configuration in a shell script within /etc/profile.d to set your own system wide environmental variables. /etc/bashrc - System wide version of .bashrc. In Fedora derived distributions, etc/bashrc also invokes /etc/profile.d/*.sh if non-login shell, but redirects output to /dev/null if non-interactive. Is only executed for interactive shells or if BASH_ENV is set to /etc/bashrc. Rationale: Setting a timeout value reduces the window of opportunity for unauthorized user access to another user's shell session that has been left unattended. It also ends the inactive session and releases the resources associated with that session. SolutionReview /etc/bashrc, /etc/profile, and all files ending in *.sh in the /etc/profile.d/ directory and remove or edit all TMOUT=_n_ entries to follow local site policy. TMOUT should not exceed 900 or be equal to 0.Configure TMOUT in one of the following files: A file in the /etc/profile.d/ directory ending in .sh /etc/profile /etc/bashrc TMOUT configuration examples: As multiple lines: TMOUT=900 readonly TMOUT export TMOUT As a single line: readonly TMOUT=900 ; export TMOUT Additional Information: The audit and remediation in this recommendation apply to bash and shell. If other shells are supported on the system, it is recommended that their configuration files are also checked. Other methods of setting a timeout exist for other shells not covered here. Ensure that the timeout conforms to your local policy. See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command 'for f in /etc/bashrc /etc/profile /etc/profile.d/*.sh ; do /usr/bin/grep -Eq '(^|^[^#]*;)\s*(readonly|export(\s+[^$#;]+\s*)*)?\s*TMOUT=(900|[1-8][0-9][0-9]|[1-9][0-9]|[1-9])\b' $f && /usr/bin/grep -Eq '(^|^[^#]*;)\s*readonly\s+TMOUT\b' $f && /usr/bin/grep -Eq '(^|^[^#]*;)\s*export\s+([^$#;]+\s+)*TMOUT\b' $f && echo "TMOUT correctly configured in file: $f"; done' did not return any result
lab-preventaThe command 'for f in /etc/bashrc /etc/profile /etc/profile.d/*.sh ; do /usr/bin/grep -Eq '(^|^[^#]*;)\s*(readonly|export(\s+[^$#;]+\s*)*)?\s*TMOUT=(900|[1-8][0-9][0-9]|[1-9][0-9]|[1-9])\b' $f && /usr/bin/grep -Eq '(^|^[^#]*;)\s*readonly\s+TMOUT\b' $f && /usr/bin/grep -Eq '(^|^[^#]*;)\s*export\s+([^$#;]+\s+)*TMOUT\b' $f && echo "TMOUT correctly configured in file: $f"; done' did not return any result
5.5.5 Ensure default user umask is configured - system wide defaultInfoThe user file-creation mode mask (umask) is use to determine the file permission for newly created directories and files. In Linux, the default permissions for any newly created directory is 0777 (rwxrwxrwx), and for any newly created file it is 0666 (rw-rw-rw-). The umask modifies the default Linux permissions by restricting (masking) these permissions. The umask is not simply subtracted, but is processed bitwise. Bits set in the umask are cleared in the resulting file mode.umask can be set with either octal or Symbolic values: Octal (Numeric) Value - Represented by either three or four digits. ie umask 0027 or umask 027. If a four digit umask is used, the first digit is ignored. The remaining three digits effect the resulting permissions for user, group, and world/other respectively. Symbolic Value - Represented by a comma separated list for User u, group g, and world/other o. The permissions listed are not masked by umask. ie a umask set by umask u=rwx,g=rx,o= is the Symbolic equivalent of the Octal umask 027. This umask would set a newly created directory with file mode drwxr-x--- and a newly created file with file mode rw-r-----. The default umask can be set to use the pam_umask module or in a System Wide Shell Configuration File. The user creating the directories or files has the discretion of changing the permissions via the chmod command, or choosing a different default umask by adding the umask command into a User Shell Configuration File, ( .bash_profile or .bashrc), in their home directory. Setting the default umask: pam_umask module: will set the umask according to the system default in /etc/login.defs and user settings, solving the problem of different umask settings with different shells, display managers, remote sessions etc. umask=<mask> value in the /etc/login.defs file is interpreted as Octal Setting USERGROUPS_ENAB to yes in /etc/login.defs (default): will enable setting of the umask group bits to be the same as owner bits. (examples: 022 -> 002, 077 -> 007) for non-root users, if the uid is the same as gid, and username is the same as the <primary group name> userdel will remove the user's group if it contains no more members, and useradd will create by default a group with the name of the user System Wide Shell Configuration File: /etc/profile - used to set system wide environmental variables on users shells. The variables are sometimes the same ones that are in the .bash_profile, however this file is used to set an initial PATH or PS1 for all shell users of the system. is only executed for interactive login shells, or shells executed with the --login parameter. /etc/profile.d - /etc/profile will execute the scripts within /etc/profile.d/*.sh. It is recommended to place your configuration in a shell script within /etc/profile.d to set your own system wide environmental variables. /etc/bashrc - System wide version of .bashrc. In Fedora derived distributions, etc/bashrc also invokes /etc/profile.d/*.sh if non-login shell, but redirects output to /dev/null if non-interactive. Is only executed for interactive shells or if BASH_ENV is set to /etc/bashrc. User Shell Configuration Files: ~/.bash_profile - Is executed to configure your shell before the initial command prompt. Is only read by login shells. ~/.bashrc - Is executed for interactive shells. only read by a shell that's both interactive and non-login Rationale: Setting a secure default value for umask ensures that users make a conscious choice about their file permissions. A permissive umask value could result in directories or files with excessive permissions that can be read and/or written to by unauthorized users. SolutionReview /etc/bashrc, /etc/profile, and all files ending in *.sh in the /etc/profile.d/ directory and remove or edit all umask entries to follow local site policy. Any remaining entries should be: umask 027, umask u=rwx,g=rx,o= or more restrictive.Configure umask in one of the following files: A file in the /etc/profile.d/ directory ending in .sh /etc/profile /etc/bashrc Example: # vi /etc/profile.d/set_umask.sh umask 027 Run the following command and remove or modify the umask of any returned files: # grep -RPi '(^|^[^#]*)\s*umask\s+([0-7][0-7][01][0-7]\b|[0-7][0-7][0-7][0-6]\b|[0-7][01][0-7]\b|[0-7][0-7][0-6]\b|(u=[rwx]{0,3},)?(g=[rwx]{0,3},)?o=[rwx]+\b|(u=[rwx]{1,3},)?g=[^rx]{1,3}(,o=[rwx]{0,3})?\b)' /etc/login.defs /etc/profile* /etc/bashrc* Follow one of the following methods to set the default user umask: Edit /etc/login.defs and edit the UMASK and USERGROUPS_ENAB lines as follows: UMASK 027 USERGROUPS_ENAB no Edit the files /etc/pam.d/password-auth and /etc/pam.d/system-auth and add or edit the following: session optional pam_umask.so OR Configure umask in one of the following files: A file in the /etc/profile.d/ directory ending in .sh /etc/profile /etc/bashrc Example: /etc/profile.d/set_umask.sh umask 027 Note: this method only applies to bash and shell. If other shells are supported on the system, it is recommended that their configuration files also are checked. Default Value: UMASK 022 Additional Information: Other methods of setting a default user umask exist If other methods are in use in your environment they should be audited The default user umask can be overridden with a user specific umask The user creating the directories or files has the discretion of changing the permissions: Using the chmod command Setting a different default umask by adding the umask command into a User Shell Configuration File, (.bashrc), in their home directory Manually changing the umask for the duration of a login session by running the umask command See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaNon-compliant file(s):
/etc/bashrc - regex '(^|^[^#]*)[\s]*umask[\s]+([0-7][0-7][01][0-7]\b|[0-7][0-7][0-7][0-6]\b|[0-7][01][0-7]\b|[0-7][0-7][0-6]\b|(u=[rwx]{0,3},)?(g=[rwx]{0,3},)?o=[rwx]+\b|(u=[rwx]{1,3},)?g=[^rx]{1,3}(,o=[rwx]{0,3})?\b)' found - expect '(^|^[^#]*)[\s]*umask[\s]+([0-7][0-7][01][0-7]\b|[0-7][0-7][0-7][0-6]\b|[0-7][01][0-7]\b|[0-7][0-7][0-6]\b|(u=[rwx]{0,3},)?(g=[rwx]{0,3},)?o=[rwx]+\b|(u=[rwx]{1,3},)?g=[^rx]{1,3}(,o=[rwx]{0,3})?\b)' found in the following lines: 71: umask 002 73: umask 022 /etc/profile - regex '(^|^[^#]*)[\s]*umask[\s]+([0-7][0-7][01][0-7]\b|[0-7][0-7][0-7][0-6]\b|[0-7][01][0-7]\b|[0-7][0-7][0-6]\b|(u=[rwx]{0,3},)?(g=[rwx]{0,3},)?o=[rwx]+\b|(u=[rwx]{1,3},)?g=[^rx]{1,3}(,o=[rwx]{0,3})?\b)' found - expect '(^|^[^#]*)[\s]*umask[\s]+([0-7][0-7][01][0-7]\b|[0-7][0-7][0-7][0-6]\b|[0-7][01][0-7]\b|[0-7][0-7][0-6]\b|(u=[rwx]{0,3},)?(g=[rwx]{0,3},)?o=[rwx]+\b|(u=[rwx]{1,3},)?g=[^rx]{1,3}(,o=[rwx]{0,3})?\b)' found in the following lines: 60: umask 002 62: umask 022 lab-preventaNon-compliant file(s):
/etc/bashrc - regex '(^|^[^#]*)[\s]*umask[\s]+([0-7][0-7][01][0-7]\b|[0-7][0-7][0-7][0-6]\b|[0-7][01][0-7]\b|[0-7][0-7][0-6]\b|(u=[rwx]{0,3},)?(g=[rwx]{0,3},)?o=[rwx]+\b|(u=[rwx]{1,3},)?g=[^rx]{1,3}(,o=[rwx]{0,3})?\b)' found - expect '(^|^[^#]*)[\s]*umask[\s]+([0-7][0-7][01][0-7]\b|[0-7][0-7][0-7][0-6]\b|[0-7][01][0-7]\b|[0-7][0-7][0-6]\b|(u=[rwx]{0,3},)?(g=[rwx]{0,3},)?o=[rwx]+\b|(u=[rwx]{1,3},)?g=[^rx]{1,3}(,o=[rwx]{0,3})?\b)' found in the following lines: 71: umask 002 73: umask 022 /etc/profile - regex '(^|^[^#]*)[\s]*umask[\s]+([0-7][0-7][01][0-7]\b|[0-7][0-7][0-7][0-6]\b|[0-7][01][0-7]\b|[0-7][0-7][0-6]\b|(u=[rwx]{0,3},)?(g=[rwx]{0,3},)?o=[rwx]+\b|(u=[rwx]{1,3},)?g=[^rx]{1,3}(,o=[rwx]{0,3})?\b)' found - expect '(^|^[^#]*)[\s]*umask[\s]+([0-7][0-7][01][0-7]\b|[0-7][0-7][0-7][0-6]\b|[0-7][01][0-7]\b|[0-7][0-7][0-6]\b|(u=[rwx]{0,3},)?(g=[rwx]{0,3},)?o=[rwx]+\b|(u=[rwx]{1,3},)?g=[^rx]{1,3}(,o=[rwx]{0,3})?\b)' found in the following lines: 60: umask 002 62: umask 022 5.5.5 Ensure default user umask is configured - system wide umaskInfoThe user file-creation mode mask (umask) is use to determine the file permission for newly created directories and files. In Linux, the default permissions for any newly created directory is 0777 (rwxrwxrwx), and for any newly created file it is 0666 (rw-rw-rw-). The umask modifies the default Linux permissions by restricting (masking) these permissions. The umask is not simply subtracted, but is processed bitwise. Bits set in the umask are cleared in the resulting file mode.umask can be set with either octal or Symbolic values: Octal (Numeric) Value - Represented by either three or four digits. ie umask 0027 or umask 027. If a four digit umask is used, the first digit is ignored. The remaining three digits effect the resulting permissions for user, group, and world/other respectively. Symbolic Value - Represented by a comma separated list for User u, group g, and world/other o. The permissions listed are not masked by umask. ie a umask set by umask u=rwx,g=rx,o= is the Symbolic equivalent of the Octal umask 027. This umask would set a newly created directory with file mode drwxr-x--- and a newly created file with file mode rw-r-----. The default umask can be set to use the pam_umask module or in a System Wide Shell Configuration File. The user creating the directories or files has the discretion of changing the permissions via the chmod command, or choosing a different default umask by adding the umask command into a User Shell Configuration File, ( .bash_profile or .bashrc), in their home directory. Setting the default umask: pam_umask module: will set the umask according to the system default in /etc/login.defs and user settings, solving the problem of different umask settings with different shells, display managers, remote sessions etc. umask=<mask> value in the /etc/login.defs file is interpreted as Octal Setting USERGROUPS_ENAB to yes in /etc/login.defs (default): will enable setting of the umask group bits to be the same as owner bits. (examples: 022 -> 002, 077 -> 007) for non-root users, if the uid is the same as gid, and username is the same as the <primary group name> userdel will remove the user's group if it contains no more members, and useradd will create by default a group with the name of the user System Wide Shell Configuration File: /etc/profile - used to set system wide environmental variables on users shells. The variables are sometimes the same ones that are in the .bash_profile, however this file is used to set an initial PATH or PS1 for all shell users of the system. is only executed for interactive login shells, or shells executed with the --login parameter. /etc/profile.d - /etc/profile will execute the scripts within /etc/profile.d/*.sh. It is recommended to place your configuration in a shell script within /etc/profile.d to set your own system wide environmental variables. /etc/bashrc - System wide version of .bashrc. In Fedora derived distributions, etc/bashrc also invokes /etc/profile.d/*.sh if non-login shell, but redirects output to /dev/null if non-interactive. Is only executed for interactive shells or if BASH_ENV is set to /etc/bashrc. User Shell Configuration Files: ~/.bash_profile - Is executed to configure your shell before the initial command prompt. Is only read by login shells. ~/.bashrc - Is executed for interactive shells. only read by a shell that's both interactive and non-login Rationale: Setting a secure default value for umask ensures that users make a conscious choice about their file permissions. A permissive umask value could result in directories or files with excessive permissions that can be read and/or written to by unauthorized users. SolutionReview /etc/bashrc, /etc/profile, and all files ending in *.sh in the /etc/profile.d/ directory and remove or edit all umask entries to follow local site policy. Any remaining entries should be: umask 027, umask u=rwx,g=rx,o= or more restrictive.Configure umask in one of the following files: A file in the /etc/profile.d/ directory ending in .sh /etc/profile /etc/bashrc Example: # vi /etc/profile.d/set_umask.sh umask 027 Run the following command and remove or modify the umask of any returned files: # grep -RPi '(^|^[^#]*)\s*umask\s+([0-7][0-7][01][0-7]\b|[0-7][0-7][0-7][0-6]\b|[0-7][01][0-7]\b|[0-7][0-7][0-6]\b|(u=[rwx]{0,3},)?(g=[rwx]{0,3},)?o=[rwx]+\b|(u=[rwx]{1,3},)?g=[^rx]{1,3}(,o=[rwx]{0,3})?\b)' /etc/login.defs /etc/profile* /etc/bashrc* Follow one of the following methods to set the default user umask: Edit /etc/login.defs and edit the UMASK and USERGROUPS_ENAB lines as follows: UMASK 027 USERGROUPS_ENAB no Edit the files /etc/pam.d/password-auth and /etc/pam.d/system-auth and add or edit the following: session optional pam_umask.so OR Configure umask in one of the following files: A file in the /etc/profile.d/ directory ending in .sh /etc/profile /etc/bashrc Example: /etc/profile.d/set_umask.sh umask 027 Note: this method only applies to bash and shell. If other shells are supported on the system, it is recommended that their configuration files also are checked. Default Value: UMASK 022 Additional Information: Other methods of setting a default user umask exist If other methods are in use in your environment they should be audited The default user umask can be overridden with a user specific umask The user creating the directories or files has the discretion of changing the permissions: Using the chmod command Setting a different default umask by adding the umask command into a User Shell Configuration File, (.bashrc), in their home directory Manually changing the umask for the duration of a login session by running the umask command See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command 'passing=""; /usr/bin/grep -Eiq '^\s*UMASK\s+(0[0-7][2-7]7|[0-7][2-7]7)\b' /etc/login.defs && /usr/bin/grep -Eqi '^\s*USERGROUPS_ENAB\s*"?no"?\b' /etc/login.defs && /usr/bin/grep -Eq '^\s*session\s+(optional|requisite|required)\s+pam_umask\.so\b' /etc/pam.d/common-session && passing=true; /usr/bin/grep -REiq '^\s*UMASK\s+\s*(0[0-7][2-7]7|[0-7][2-7]7|u=(r?|w?|x?)(r?|w?|x?)(r?|w?|x?),g=(r?x?|x?r?),o=)\b' /etc/profile* /etc/bashrc* && passing=true; [ "$passing" = true ] && echo "Default user umask is set" || echo "Default user umask not found or invalid"' returned :
Default user umask not found or invalid lab-preventaThe command 'passing=""; /usr/bin/grep -Eiq '^\s*UMASK\s+(0[0-7][2-7]7|[0-7][2-7]7)\b' /etc/login.defs && /usr/bin/grep -Eqi '^\s*USERGROUPS_ENAB\s*"?no"?\b' /etc/login.defs && /usr/bin/grep -Eq '^\s*session\s+(optional|requisite|required)\s+pam_umask\.so\b' /etc/pam.d/common-session && passing=true; /usr/bin/grep -REiq '^\s*UMASK\s+\s*(0[0-7][2-7]7|[0-7][2-7]7|u=(r?|w?|x?)(r?|w?|x?)(r?|w?|x?),g=(r?x?|x?r?),o=)\b' /etc/profile* /etc/bashrc* && passing=true; [ "$passing" = true ] && echo "Default user umask is set" || echo "Default user umask not found or invalid"' returned :
Default user umask not found or invalid 5.6 Ensure root login is restricted to system consoleInfoThe file /etc/securetty contains a list of valid terminals that may be logged in directly as root.Rationale: Since the system console has special properties to handle emergency situations, it is important to ensure that the console is in a physically secure location and that unauthorized consoles have not been defined. SolutionRemove entries for any consoles that are not in a physically secure location.See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command returned :
vc/1 vc/2 vc/3 vc/4 vc/5 vc/6 vc/7 vc/8 vc/9 vc/10 vc/11 tty1 tty2 tty3 tty4 tty5 tty6 tty7 tty8 tty9 tty10 tty11 ttyS0 ttysclp0 sclp_line0 3270/tty1 hvc0 hvc1 hvc2 hvc3 hvc4 hvc5 hvc6 hvc7 hvsi0 hvsi1 hvsi2 xvc0 lab-preventaThe command returned :
vc/1 vc/2 vc/3 vc/4 vc/5 vc/6 vc/7 vc/8 vc/9 vc/10 vc/11 tty1 tty2 tty3 tty4 tty5 tty6 tty7 tty8 tty9 tty10 tty11 ttyS0 ttysclp0 sclp_line0 3270/tty1 hvc0 hvc1 hvc2 hvc3 hvc4 hvc5 hvc6 hvc7 hvsi0 hvsi1 hvsi2 xvc0 5.7 Ensure access to the su command is restrictedInfoThe su command allows a user to run a command or shell as another user. The program has been superseded by sudo, which allows for more granular control over privileged access. Normally, the su command can be executed by any user. By uncommenting the pam_wheel.so statement in /etc/pam.d/su, the su command will only allow users in a specific groups to execute su. This group should be empty to reinforce the use of sudo for privileged access.Rationale: Restricting the use of su , and using sudo in its place, provides system administrators better control of the escalation of user privileges to execute privileged commands. The sudo utility also provides a better logging and audit mechanism, as it can log each command executed via sudo , whereas su can only record that a user executed the su program. SolutionCreate an empty group that will be specified for use of the su command. The group should be named according to site policy.Example: # groupadd sugroup Add the following line to the /etc/pam.d/su file, specifying the empty group: auth required pam_wheel.so use_uid group=sugroup See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command 'groupname=$(/bin/grep -P "^[\s]*auth[\s]+required[\s]+pam_wheel\.so[\s]+(?=.*group=.*).*$" /etc/pam.d/su | /usr/bin/cut -d'=' -f2); if [ -z "$groupname" ]; then echo "Group not set in /etc/pam.d/su"; else /bin/grep "${groupname}" /etc/group; fi' returned :
Group not set in /etc/pam.d/su lab-preventaThe command 'groupname=$(/bin/grep -P "^[\s]*auth[\s]+required[\s]+pam_wheel\.so[\s]+(?=.*group=.*).*$" /etc/pam.d/su | /usr/bin/cut -d'=' -f2); if [ -z "$groupname" ]; then echo "Group not set in /etc/pam.d/su"; else /bin/grep "${groupname}" /etc/group; fi' returned :
Group not set in /etc/pam.d/su 6.1.10 Ensure no world writable files existInfoUnix-based systems support variable settings to control access to files. World writable files are the least secure. See the chmod(2) man page for more information.Rationale: Data in world-writable files can be modified and compromised by any user on the system. World writable files may also indicate an incorrectly written script or program that could potentially be the cause of a larger compromise to the system's integrity. SolutionRemoving write access for the 'other' category ( chmod o-w <filename> ) is advisable, but always consult relevant vendor documentation to avoid breaking any application dependencies on a given file.See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventa The following 35 files are world writeable:
/var/lib/docker/overlay2/ce7d9ef023311bc2084e61d2187c8cadf458c899dfd7d788a7eace406929c003/diff/usr/local/etc/redis/redis.conf.tpl owner: root, group: root, permissions: 0666 /var/lib/docker/overlay2/c381b3a5c0f476390c4178c19d0de32469724ce186ff0c703227756e0536b5af/diff/usr/local/bin/run-redis.sh owner: root, group: root, permissions: 0777 /var/lib/docker/overlay2/7d87a542d58eb05ec70ed1ba2a18aa212da2197d7eca0862ce39e76f48d7886b/diff/usr/local/etc/redis/redis.conf.tpl owner: polkitd, group: input, permissions: 0666 /var/lib/docker/overlay2/3032a07e544db172a3288c86262d4588cd8389c904a53db91e55d6c226e7eef9/diff/opt/duo/dist/etc/sites.d/admin.nginx.conf owner: root, group: root, permissions: 0666 /var/lib/docker/overlay2/e8ab0c6366876c4a7147af6f3e58bc79588afa58030b757734cf2092c0a11e6e/diff/opt/duo/certs/ca-bundle.crt owner: root, group: root, permissions: 0666 /var/lib/docker/overlay2/49901d8c6b17dc5379e9d7eabb5cf6727cc0fc0213cf4027700bd69303e5fc2a/diff/opt/duo/certs/ssl.crt owner: root, group: root, permissions: 0666 /var/lib/docker/overlay2/9c86ccfec0c3c1c80dd76e98b612c0cedf27948807cfa60d1d753563fed339db/diff/opt/duo/certs/client-certs.crt owner: root, group: root, permissions: 0666 /var/lib/docker/overlay2/07f3b6f1e978d152c8543abd86af7dab9fcaea4ca95f655695cc954190f5f1aa/diff/opt/duo/certs/ssl.key owner: root, group: root, permissions: 0666 /var/lib/docker/overlay2/c49e83622694a622c738503b855638b44e814a44e037f10500f0c6b4dc1df0b9/diff/opt/duo/etc/aperture.toml owner: root, group: root, permissions: 0666 /var/lib/docker/overlay2/3f31c9e38e6bfa3e391fcf9c5c60a48e54ec580e5d6fa471b4648686c12fdf7f/diff/etc/supervisor/supervisord.conf owner: root, group: root, permissions: 0666 /var/lib/docker/overlay2/a5cda04387b23c9dea92e091240b2082c554fcf0d8fd828af926daa22c246627/diff/etc/supervisor/conf.d/admin.supervisord.conf owner: root, group: root, permissions: 0666 [...] lab-preventa The following 35 files are world writeable:
/var/lib/docker/overlay2/ce7d9ef023311bc2084e61d2187c8cadf458c899dfd7d788a7eace406929c003/diff/usr/local/etc/redis/redis.conf.tpl owner: root, group: root, permissions: 0666 /var/lib/docker/overlay2/c381b3a5c0f476390c4178c19d0de32469724ce186ff0c703227756e0536b5af/diff/usr/local/bin/run-redis.sh owner: root, group: root, permissions: 0777 /var/lib/docker/overlay2/7d87a542d58eb05ec70ed1ba2a18aa212da2197d7eca0862ce39e76f48d7886b/diff/usr/local/etc/redis/redis.conf.tpl owner: polkitd, group: input, permissions: 0666 /var/lib/docker/overlay2/3032a07e544db172a3288c86262d4588cd8389c904a53db91e55d6c226e7eef9/diff/opt/duo/dist/etc/sites.d/admin.nginx.conf owner: root, group: root, permissions: 0666 /var/lib/docker/overlay2/e8ab0c6366876c4a7147af6f3e58bc79588afa58030b757734cf2092c0a11e6e/diff/opt/duo/certs/ca-bundle.crt owner: root, group: root, permissions: 0666 /var/lib/docker/overlay2/49901d8c6b17dc5379e9d7eabb5cf6727cc0fc0213cf4027700bd69303e5fc2a/diff/opt/duo/certs/ssl.crt owner: root, group: root, permissions: 0666 /var/lib/docker/overlay2/9c86ccfec0c3c1c80dd76e98b612c0cedf27948807cfa60d1d753563fed339db/diff/opt/duo/certs/client-certs.crt owner: root, group: root, permissions: 0666 /var/lib/docker/overlay2/07f3b6f1e978d152c8543abd86af7dab9fcaea4ca95f655695cc954190f5f1aa/diff/opt/duo/certs/ssl.key owner: root, group: root, permissions: 0666 /var/lib/docker/overlay2/c49e83622694a622c738503b855638b44e814a44e037f10500f0c6b4dc1df0b9/diff/opt/duo/etc/aperture.toml owner: root, group: root, permissions: 0666 /var/lib/docker/overlay2/3f31c9e38e6bfa3e391fcf9c5c60a48e54ec580e5d6fa471b4648686c12fdf7f/diff/etc/supervisor/supervisord.conf owner: root, group: root, permissions: 0666 /var/lib/docker/overlay2/a5cda04387b23c9dea92e091240b2082c554fcf0d8fd828af926daa22c246627/diff/etc/supervisor/conf.d/admin.supervisord.conf owner: root, group: root, permissions: 0666 [...] 6.1.11 Ensure no unowned files or directories existInfoSometimes when administrators delete users from the password file they neglect to remove all files owned by those users from the system.Rationale: A new user who is assigned the deleted user's user ID or group ID may then end up 'owning' these files, and thus have more access on the system than was intended. SolutionLocate files that are owned by users or groups not listed in the system configuration files, and reset the ownership of these files to some active user on the system as appropriate.See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventa The following 255 files are orphaned:
/var/lib/docker/overlay2/8bafcdedb44a6b9126e62111b880412ba21681ece4065aefd3471a60bc9df502/diff/var/cache/apt/archives/partial owner: 100, group: root, permissions: 0700 /var/lib/docker/overlay2/8bafcdedb44a6b9126e62111b880412ba21681ece4065aefd3471a60bc9df502/diff/var/lib/apt/lists/auxfiles owner: 100, group: root, permissions: 0755 /var/lib/docker/overlay2/d98cbb6528dfc5a81fe9e9de2167809dbf68d686e784555fa3abbdab829cac04/diff/var/cache/apt/archives/partial owner: 100, group: root, permissions: 0700 /var/lib/docker/overlay2/d98cbb6528dfc5a81fe9e9de2167809dbf68d686e784555fa3abbdab829cac04/diff/var/lib/apt/lists/auxfiles owner: 100, group: root, permissions: 0755 /var/lib/docker/overlay2/e044a56441218104fcc1de3786407b6101f20eb45f9a107638af1ed1948071d2/diff/opt/duo/admin owner: 65534, group: root, permissions: 0755 /var/lib/docker/overlay2/e044a56441218104fcc1de3786407b6101f20eb45f9a107638af1ed1948071d2/diff/opt/duo/admin/__init__.pyc owner: 65534, group: root, permissions: 0644 /var/lib/docker/overlay2/e044a56441218104fcc1de3786407b6101f20eb45f9a107638af1ed1948071d2/diff/opt/duo/admin/__main__.pyc owner: 65534, group: root, permissions: 0644 /var/lib/docker/overlay2/e044a56441218104fcc1de3786407b6101f20eb45f9a107638af1ed1948071d2/diff/opt/duo/admin/admin.pyc owner: 65534, group: root, permissions: 0644 /var/lib/docker/overlay2/e044a56441218104fcc1de3786407b6101f20eb45f9a107638af1ed1948071d2/diff/opt/duo/admin/api owner: 65534, group: root, permissions: 0755 /var/lib/docker/overlay2/e044a56441218104fcc1de3786407b6101f20eb45f9a107638af1ed1948071d2/diff/opt/duo/admin/api/__init__.pyc owner: 65534, group: root, permissions: 0644 /var/lib/docker/overlay2/e044a56441218104fcc1de3786407b6101f20eb45f9a107638af1ed1948071d2/diff/opt/duo/admin/api/application_relays.pyc owner: 65534, group: root, permissions: 0644 [...] lab-preventa The following 255 files are orphaned:
/var/lib/docker/overlay2/8bafcdedb44a6b9126e62111b880412ba21681ece4065aefd3471a60bc9df502/diff/var/cache/apt/archives/partial owner: 100, group: root, permissions: 0700 /var/lib/docker/overlay2/8bafcdedb44a6b9126e62111b880412ba21681ece4065aefd3471a60bc9df502/diff/var/lib/apt/lists/auxfiles owner: 100, group: root, permissions: 0755 /var/lib/docker/overlay2/d98cbb6528dfc5a81fe9e9de2167809dbf68d686e784555fa3abbdab829cac04/diff/var/cache/apt/archives/partial owner: 100, group: root, permissions: 0700 /var/lib/docker/overlay2/d98cbb6528dfc5a81fe9e9de2167809dbf68d686e784555fa3abbdab829cac04/diff/var/lib/apt/lists/auxfiles owner: 100, group: root, permissions: 0755 /var/lib/docker/overlay2/e044a56441218104fcc1de3786407b6101f20eb45f9a107638af1ed1948071d2/diff/opt/duo/admin owner: 65534, group: root, permissions: 0755 /var/lib/docker/overlay2/e044a56441218104fcc1de3786407b6101f20eb45f9a107638af1ed1948071d2/diff/opt/duo/admin/__init__.pyc owner: 65534, group: root, permissions: 0644 /var/lib/docker/overlay2/e044a56441218104fcc1de3786407b6101f20eb45f9a107638af1ed1948071d2/diff/opt/duo/admin/__main__.pyc owner: 65534, group: root, permissions: 0644 /var/lib/docker/overlay2/e044a56441218104fcc1de3786407b6101f20eb45f9a107638af1ed1948071d2/diff/opt/duo/admin/admin.pyc owner: 65534, group: root, permissions: 0644 /var/lib/docker/overlay2/e044a56441218104fcc1de3786407b6101f20eb45f9a107638af1ed1948071d2/diff/opt/duo/admin/api owner: 65534, group: root, permissions: 0755 /var/lib/docker/overlay2/e044a56441218104fcc1de3786407b6101f20eb45f9a107638af1ed1948071d2/diff/opt/duo/admin/api/__init__.pyc owner: 65534, group: root, permissions: 0644 /var/lib/docker/overlay2/e044a56441218104fcc1de3786407b6101f20eb45f9a107638af1ed1948071d2/diff/opt/duo/admin/api/application_relays.pyc owner: 65534, group: root, permissions: 0644 [...] 6.1.12 Ensure no ungrouped files or directories existInfoSometimes when administrators delete users or groups from the system they neglect to remove all files owned by those users or groups.Rationale: A new user who is assigned the deleted user's user ID or group ID may then end up 'owning' these files, and thus have more access on the system than was intended. SolutionLocate files that are owned by users or groups not listed in the system configuration files, and reset the ownership of these files to some active user on the system as appropriate.See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventa The following 40 files are orphaned:
/var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/etc/gshadow owner: root, group: 42, permissions: 0640 /var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/etc/shadow owner: root, group: 42, permissions: 0640 /var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/etc/shadow- owner: root, group: 42, permissions: 0640 /var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/run/utmp owner: root, group: 43, permissions: 0664 /var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/sbin/unix_chkpwd owner: root, group: 42, permissions: 2755 /var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/usr/bin/chage owner: root, group: 42, permissions: 2755 /var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/usr/bin/expiry owner: root, group: 42, permissions: 2755 /var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/var/log/btmp owner: root, group: 43, permissions: 0660 /var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/var/log/lastlog owner: root, group: 43, permissions: 0664 /var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/var/log/wtmp owner: root, group: 43, permissions: 0664 /var/lib/docker/overlay2/c5b4dedd624584baffe74d8b1b30d9fe7f91a928a152508b8c06f9a13c4f293e/diff/etc/gshadow owner: root, group: 42, permissions: 0640 /var/lib/docker/overlay2/c5b4dedd624584baffe74d8b1b30d9fe7f91a928a152508b8c06f9a13c4f293e/diff/etc/gshadow- owner: root, group: 42, permissions: 0640 /var/lib/docker/overlay2/c5b4dedd624584baffe74d8b1b30d9fe7f91a928a152508b8c06f9a13c4f293e/diff/etc/shadow [...] lab-preventa The following 40 files are orphaned:
/var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/etc/gshadow owner: root, group: 42, permissions: 0640 /var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/etc/shadow owner: root, group: 42, permissions: 0640 /var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/etc/shadow- owner: root, group: 42, permissions: 0640 /var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/run/utmp owner: root, group: 43, permissions: 0664 /var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/sbin/unix_chkpwd owner: root, group: 42, permissions: 2755 /var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/usr/bin/chage owner: root, group: 42, permissions: 2755 /var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/usr/bin/expiry owner: root, group: 42, permissions: 2755 /var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/var/log/btmp owner: root, group: 43, permissions: 0660 /var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/var/log/lastlog owner: root, group: 43, permissions: 0664 /var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/var/log/wtmp owner: root, group: 43, permissions: 0664 /var/lib/docker/overlay2/c5b4dedd624584baffe74d8b1b30d9fe7f91a928a152508b8c06f9a13c4f293e/diff/etc/gshadow owner: root, group: 42, permissions: 0640 /var/lib/docker/overlay2/c5b4dedd624584baffe74d8b1b30d9fe7f91a928a152508b8c06f9a13c4f293e/diff/etc/gshadow- owner: root, group: 42, permissions: 0640 /var/lib/docker/overlay2/c5b4dedd624584baffe74d8b1b30d9fe7f91a928a152508b8c06f9a13c4f293e/diff/etc/shadow [...] Audits SKIPPEDAudits PASSED1.1.1.1 Ensure mounting of cramfs filesystems is disabled - lsmodInfoThe cramfs filesystem type is a compressed read-only Linux filesystem embedded in small footprint systems. A cramfs image can be used without having to first decompress the image.Rationale: Removing support for unneeded filesystem types reduces the local attack surface of the server. If this filesystem type is not needed, disable it. SolutionEdit or create a file in the /etc/modprobe.d/ directory ending in .conf Example: vim /etc/modprobe.d/cramfs.conf and add the following line:install cramfs /bin/true Run the following command to unload the cramfs module: # rmmod cramfs See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/lsmod | /usr/bin/grep cramfs | /usr/bin/awk '{print} END {if (NR == 0) print "pass" ; else print "fail"}'' returned :
pass lab-preventaThe command '/usr/sbin/lsmod | /usr/bin/grep cramfs | /usr/bin/awk '{print} END {if (NR == 0) print "pass" ; else print "fail"}'' returned :
pass 1.1.1.3 Ensure mounting of udf filesystems is disabled - lsmodInfoThe udf filesystem type is the universal disk format used to implement ISO/IEC 13346 and ECMA-167 specifications. This is an open vendor filesystem type for data storage on a broad range of media. This filesystem type is necessary to support writing DVDs and newer optical disc formats.Rationale: Removing support for unneeded filesystem types reduces the local attack surface of the system. If this filesystem type is not needed, disable it. SolutionEdit or create a file in the /etc/modprobe.d/ directory ending in .conf Example: vi /etc/modprobe.d/udf.conf and add the following line:install udf /bin/true Run the following command to unload the udf module: # rmmod udf See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/sbin/lsmod udf | /usr/bin/awk '{print} END {if (NR == 0) print "pass" ; else print "fail"}'' returned :
Usage: /sbin/lsmod pass lab-preventaThe command '/sbin/lsmod udf | /usr/bin/awk '{print} END {if (NR == 0) print "pass" ; else print "fail"}'' returned :
Usage: /sbin/lsmod pass 1.1.12 Ensure /var/tmp partition includes the noexec optionInfoThe noexec mount option specifies that the filesystem cannot contain executable binaries.Rationale: Since the /var/tmp filesystem is only intended for temporary file storage, set this option to ensure that users cannot run executable binaries from /var/tmp. SolutionFor existing /var/tmp partitions, edit the /etc/fstab file and add noexec to the fourth field (mounting options) of the /var/tmp entry. See the fstab(5) manual page for more information.Run the following command to remount /var/tmp : # mount -o remount,noexec /var/tmp See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa1.1.13 Ensure /var/tmp partition includes the nodev optionInfoThe nodev mount option specifies that the filesystem cannot contain special devices.Rationale: Since the /var/tmp filesystem is not intended to support devices, set this option to ensure that users cannot attempt to create block or character special devices in /var/tmp . SolutionFor existing /var/tmp partitions, edit the /etc/fstab file and add nodev to the fourth field (mounting options) of the /var/tmp entry. See the fstab(5) manual page for more information.Run the following command to remount /var/tmp: # mount -o remount,nodev /var/tmp See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa1.1.14 Ensure /var/tmp partition includes the nosuid optionInfoThe nosuid mount option specifies that the filesystem cannot contain setuid files.Rationale: Since the /var/tmp filesystem is only intended for temporary file storage, set this option to ensure that users cannot create setuid files in /var/tmp . SolutionFor existing /var/tmp partitions, edit the /etc/fstab file and add nosuid to the fourth field (mounting options) of the /var/tmp entry. See the fstab(5) manual page for more information.Run the following command to remount /var/tmp : # mount -o remount,nosuid /var/tmp See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa1.1.18 Ensure /home partition includes the nodev optionInfoThe nodev mount option specifies that the filesystem cannot contain special devices.Rationale: Since the user partitions are not intended to support devices, set this option to ensure that users cannot attempt to create block or character special devices. SolutionFor existing /home partitions, edit the /etc/fstab file and add nodev to the fourth field (mounting options) of the /home entry. See the fstab(5) manual page for more information.Run the following command to remount /home: # mount -o remount,nodev /home Additional Information: The actions in this recommendation refer to the /home partition, which is the default user partition. If you have created other user partitions, it is recommended that the Remediation and Audit steps be applied to these partitions as well. See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa1.1.19 Ensure removable media partitions include noexec optionInfoThe noexec mount option specifies that the filesystem cannot contain executable binaries.Rationale: Setting this option on a file system prevents users from executing programs from the removable media. This deters users from being able to introduce potentially malicious software on the system. SolutionEdit the /etc/fstab file and add noexec to the fourth field (mounting options) of all removable media partitions. Look for entries that have mount points that contain words such as floppy or cdrom. See the fstab(5) manual page for more information.See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaNo matching files were found
lab-preventaNo matching files were found
1.1.20 Ensure nodev option set on removable media partitionsInfoThe nodev mount option specifies that the filesystem cannot contain special devices.Rationale: Removable media containing character and block special devices could be used to circumvent security controls by allowing non-root users to access sensitive device files such as /dev/kmem or the raw disk partitions. SolutionEdit the /etc/fstab file and add nodev to the fourth field (mounting options) of all removable media partitions. Look for entries that have mount points that contain words such as floppy or cdrom. See the fstab(5) manual page for more information.See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaNo matching files were found
lab-preventaNo matching files were found
1.1.21 Ensure nosuid option set on removable media partitionsInfoThe nosuid mount option specifies that the filesystem cannot contain setuid files.Rationale: Setting this option on a file system prevents users from introducing privileged programs onto the system and allowing non-root users to execute them. SolutionEdit the /etc/fstab file and add nosuid to the fourth field (mounting options) of all removable media partitions. Look for entries that have mount points that contain words such as floppy or cdrom. See the fstab(5) manual page for more information.See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaNo matching files were found
lab-preventaNo matching files were found
1.1.22 Ensure sticky bit is set on all world-writable directoriesInfoSetting the sticky bit on world writable directories prevents users from deleting or renaming files in that directory that are not owned by them.Rationale: This feature prevents the ability to delete or rename files in world writable directories (such as /tmp ) that are owned by another user. SolutionRun the following command to set the sticky bit on all world writable directories:# df --local -P | awk '{if (NR!=1) print $6}' | xargs -I '{}' find '{}' -xdev -type d ( -perm -0002 -a ! -perm -1000 ) 2>/dev/null | xargs -I '{}' chmod a+t '{}' See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaNo issues found.
lab-preventaNo issues found.
1.1.23 Disable AutomountingInfoautofs allows automatic mounting of devices, typically including CD/DVDs and USB drives.Rationale: With automounting enabled anyone with physical access could attach a USB drive or disc and have its contents available in system even if they lacked permissions to mount it themselves. Impact: The use of portable hard drives is very common for workstation users. If your organization allows the use of portable storage or media on workstations and physical access controls to workstations is considered adequate there is little value add in turning off automounting. SolutionRun the following command to mask autofs:# systemctl --now mask autofs OR run the following command to remove autofs # yum remove autofs Additional Information: Additional methods of disabling a service exist. Consult your distribution documentation for appropriate methods. This control should align with the tolerance of the use of portable drives and optical media in the organization. On a server requiring an admin to manually mount media can be part of defense-in-depth to reduce the risk of unapproved software or information being introduced or proprietary software or information being exfiltrated. If admins commonly use flash drives and Server access has sufficient physical controls, requiring manual mounting may not increase security. See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command returned :
Failed to get unit file state for autofs.service: No such file or directory disabled 1.1.24 Disable USB Storage - lsmodInfoUSB storage provides a means to transfer and store files insuring persistence and availability of the files independent of network connection status. Its popularity and utility has led to USB-based malware being a simple and common means for network infiltration and a first step to establishing a persistent threat within a networked environment.Rationale: Restricting USB access on the system will decrease the physical attack surface for a device and diminish the possible vectors to introduce malware. SolutionEdit or create a file in the /etc/modprobe.d/ directory ending in .conf Example: vim /etc/modprobe.d/usb_storage.conf Add the following line:install usb-storage /bin/true Run the following command to unload the usb-storage module: rmmod usb-storage Additional Information: An alternative solution to disabling the usb-storage module may be found in USBGuard. Use of USBGuard and construction of USB device policies should be done in alignment with site policy. See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/lsmod | /usr/bin/grep usb-storage | /usr/bin/awk '{print} END {if (NR == 0) print "pass" ; else print "fail"}'' returned :
pass 1.1.3 Ensure noexec option set on /tmp partitionInfoThe noexec mount option specifies that the filesystem cannot contain executable binaries.Rationale: Since the /tmp filesystem is only intended for temporary file storage, set this option to ensure that users cannot run executable binaries from /tmp. SolutionEdit the /etc/fstab file OR the /etc/systemd/system/local-fs.target.wants/tmp.mount file:IF /etc/fstab is used to mount /tmp Edit the /etc/fstab file and add noexec to the fourth field (mounting options) for the /tmp partition. See the fstab(5) manual page for more information. Run the following command to remount /tmp: # mount -o remount,noexec /tmp OR if systemd is used to mount /tmp:_ Edit /etc/systemd/system/local-fs.target.wants/tmp.mount to add noexec to the /tmp mount options: [Mount] Options=mode=1777,strictatime,noexec,nodev,nosuid Run the following command to restart the systemd daemon: # systemctl daemon-reload Run the following command to restart tmp.mount # systemctl restart tmp.mount See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa1.1.4 Ensure nodev option set on /tmp partitionInfoThe nodev mount option specifies that the filesystem cannot contain special devices.Rationale: Since the /tmp filesystem is not intended to support devices, set this option to ensure that users cannot attempt to create block or character special devices in /tmp . SolutionEdit the /etc/fstab file OR the /etc/systemd/system/local-fs.target.wants/tmp.mount file:IF /etc/fstab is used to mount /tmp Edit the /etc/fstab file and add nodev to the fourth field (mounting options) for the /tmp partition. See the fstab(5) manual page for more information. Run the following command to remount /tmp: # mount -o remount,nodev /tmp OR if systemd is used to mount /tmp: Edit /etc/systemd/system/local-fs.target.wants/tmp.mount to add nodev to the /tmp mount options: [Mount] Options=mode=1777,strictatime,noexec,nodev,nosuid Run the following command to restart the systemd daemon: # systemctl daemon-reload Run the following command to restart tmp.mount # systemctl restart tmp.mount See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa1.1.5 Ensure nosuid option set on /tmp partitionInfoThe nosuid mount option specifies that the filesystem cannot contain setuid files.Rationale: Since the /tmp filesystem is only intended for temporary file storage, set this option to ensure that users cannot create setuid files in /tmp. SolutionIF /etc/fstab is used to mount /tmp Edit the /etc/fstab file and add nosuid to the fourth field (mounting options) for the /tmp partition. See the fstab(5) manual page for more information.Run the following command to remount /tmp : # mount -o remount,nosuid /tmp OR if systemd is used to mount /tmp: Edit /etc/systemd/system/local-fs.target.wants/tmp.mount to add nosuid to the /tmp mount options: [Mount] Options=mode=1777,strictatime,noexec,nodev,nosuid Run the following command to restart the systemd daemon: # systemctl daemon-reload Run the following command to restart tmp.mount: # systemctl restart tmp.mount See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa1.1.6 Ensure /dev/shm is configured - mountInfo/dev/shm is a traditional shared memory concept. One program will create a memory portion, which other processes (if permitted) can access. Mounting tmpfs at /dev/shm is handled automatically by systemd.Rationale: Any user can upload and execute files inside the /dev/shm similar to the /tmp partition. Configuring /dev/shm allows an administrator to set the noexec option on the mount, making /dev/shm useless for an attacker to install executable code. It would also prevent an attacker from establishing a hardlink to a system setuid program and wait for it to be updated. Once the program was updated, the hardlink would be broken and the attacker would have his own copy of the program. If the program happened to have a security vulnerability, the attacker could continue to exploit the known flaw. SolutionEdit /etc/fstab and add or edit the following line:tmpfs /dev/shm tmpfs defaults,noexec,nodev,nosuid,seclabel 0 0 Run the following command to remount /dev/shm: # mount -o remount,noexec,nodev,nosuid /dev/shm Additional Information: An entry for /dev/shm in /etc/fstab will take precedence. tmpfs can be resized using the size={size} parameter in /etc/fstab. If we don't specify the size, it will be half the RAM. Resize tmpfs example: tmpfs /dev/shm tmpfs defaults,noexec,nodev,nosuid,size=2G 0 0 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/bin/mount | /bin/egrep '\s/dev/shm\s'' returned :
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,seclabel) lab-preventaThe command '/bin/mount | /bin/egrep '\s/dev/shm\s'' returned :
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,seclabel) 1.1.8 Ensure nodev option set on /dev/shm partitionInfoThe nodev mount option specifies that the filesystem cannot contain special devices.Rationale: Since the /dev/shm filesystem is not intended to support devices, set this option to ensure that users cannot attempt to create special devices in /dev/shm partitions. SolutionEdit the /etc/fstab file and add nodev to the fourth field (mounting options) for the /dev/shm partition. See the fstab(5) manual page for more information.Run the following command to remount /dev/shm: # mount -o remount,noexec,nodev,nosuid /dev/shm Additional Information: /dev/shm is mounted automatically by systemd. /dev/shm needs to be added to /etc/fstab to add mount options even though it is already being mounted on boot. See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/bin/mount | /bin/grep 'on /dev/shm '' returned :
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,seclabel) lab-preventaThe command '/bin/mount | /bin/grep 'on /dev/shm '' returned :
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,seclabel) 1.1.9 Ensure nosuid option set on /dev/shm partitionInfoThe nosuid mount option specifies that the filesystem cannot contain setuid files.Rationale: Setting this option on a file system prevents users from introducing privileged programs onto the system and allowing non-root users to execute them. SolutionEdit the /etc/fstab file and add nosuid to the fourth field (mounting options) for the /dev/shm partition. See the fstab(5) manual page for more information.Run the following command to remount /dev/shm: # mount -o remount,noexec,nodev,nosuid /dev/shm Additional Information: /dev/shm is mounted automatically by systemd. /dev/shm needs to be added to /etc/fstab to add mount options even though it is already being mounted on boot. See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/bin/mount | /bin/grep 'on /dev/shm '' returned :
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,seclabel) lab-preventaThe command '/bin/mount | /bin/grep 'on /dev/shm '' returned :
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,seclabel) 1.2.1 Ensure GPG keys are configuredInfoMost packages managers implement GPG key signing to verify package integrity during installation.Rationale: It is important to ensure that updates are obtained from a valid source to protect against spoofing that could lead to the inadvertent installation of malware on the system. NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance. SolutionUpdate your package manager GPG keys in accordance with site policy.See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command returned :
gpg(CentOS-7 Key (CentOS 7 Official Signing Key) <security@centos.org>) gpg(Docker Release (CE rpm) <docker@docker.com>) lab-preventaThe command returned :
gpg(CentOS-7 Key (CentOS 7 Official Signing Key) <security@centos.org>) gpg(Docker Release (CE rpm) <docker@docker.com>) 1.2.3 Ensure gpgcheck is globally activatedInfoThe gpgcheck option, found in the main section of the /etc/yum.conf and individual /etc/yum/repos.d/*.repo files determines if an RPM package's signature is checked prior to its installation.Rationale: It is important to ensure that an RPM's package signature is always checked prior to installation to ensure that the software is obtained from a trusted source. SolutionEdit /etc/yum.conf and set 'gpgcheck=1' in the [main] section.Edit any failing files in /etc/yum.repos.d/*.repo and set all instances of gpgcheck to 1. See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventa Compliant file(s):
/etc/yum.conf - regex '^[\s]*gpgcheck[\s]*=' found - expect '^[\s]*gpgcheck[\s]*=[\s]*1[\s]*$' found in the following lines: 8: gpgcheck=1 /etc/yum.repos.d/CentOS-Base.repo - regex '^[\s]*gpgcheck[\s]*=' found - expect '^[\s]*gpgcheck[\s]*=[\s]*1[\s]*$' found in the following lines: 17: gpgcheck=1 25: gpgcheck=1 33: gpgcheck=1 41: gpgcheck=1 /etc/yum.repos.d/CentOS-CR.repo - regex '^[\s]*gpgcheck[\s]*=' found - expect '^[\s]*gpgcheck[\s]*=[\s]*1[\s]*$' found in the following lines: 26: gpgcheck=1 /etc/yum.repos.d/CentOS-Debuginfo.repo - regex '^[\s]*gpgcheck[\s]*=' found - expect '^[\s]*gpgcheck[\s]*=[\s]*1[\s]*$' found in the following lines: 18: gpgcheck=1 /etc/yum.repos.d/CentOS-Media.repo - regex '^[\s]*gpgcheck[\s]*=' found - expect '^[\s]*gpgcheck[\s]*=[\s]*1[\s]*$' found in the following lines: 19: gpgcheck=1 /etc/yum.repos.d/CentOS-Sources.repo - regex '^[\s]*gpgcheck[\s]*=' found - expect '^[\s]*gpgcheck[\s]*=[\s]*1[\s]*$' found in the following lines: 16: gpgcheck=1 24: gpgcheck=1 32: gpgcheck=1 40: gpgcheck=1 /etc/yum.repos.d/CentOS-Vault.repo - regex '^[\s]*gpgcheck[\s]*=' found - expect '^[\s]*gpgcheck[\s]*=[\s]*1[\s]*$' found in the following lines: 8: gpgcheck=1 15: gpgcheck=1 22: gpgcheck=1 29: gpgcheck=1 36: gpgcheck=1 44: gpgcheck=1 51: gpgcheck=1 58: gpgcheck=1 65: gpgcheck=1 72: gpgcheck=1 80: gpgcheck=1 87: gpgcheck=1 94: gpgcheck=1 101: gpgcheck=1 108: gpgcheck=1 116: gpgcheck=1 123: gpgcheck=1 130: gpgcheck=1 137: gpgcheck=1 144: gpgcheck=1 152: gpgcheck=1 [...] lab-preventa Compliant file(s):
/etc/yum.conf - regex '^[\s]*gpgcheck[\s]*=' found - expect '^[\s]*gpgcheck[\s]*=[\s]*1[\s]*$' found in the following lines: 8: gpgcheck=1 /etc/yum.repos.d/CentOS-Base.repo - regex '^[\s]*gpgcheck[\s]*=' found - expect '^[\s]*gpgcheck[\s]*=[\s]*1[\s]*$' found in the following lines: 17: gpgcheck=1 25: gpgcheck=1 33: gpgcheck=1 41: gpgcheck=1 /etc/yum.repos.d/CentOS-CR.repo - regex '^[\s]*gpgcheck[\s]*=' found - expect '^[\s]*gpgcheck[\s]*=[\s]*1[\s]*$' found in the following lines: 26: gpgcheck=1 /etc/yum.repos.d/CentOS-Debuginfo.repo - regex '^[\s]*gpgcheck[\s]*=' found - expect '^[\s]*gpgcheck[\s]*=[\s]*1[\s]*$' found in the following lines: 18: gpgcheck=1 /etc/yum.repos.d/CentOS-Media.repo - regex '^[\s]*gpgcheck[\s]*=' found - expect '^[\s]*gpgcheck[\s]*=[\s]*1[\s]*$' found in the following lines: 19: gpgcheck=1 /etc/yum.repos.d/CentOS-Sources.repo - regex '^[\s]*gpgcheck[\s]*=' found - expect '^[\s]*gpgcheck[\s]*=[\s]*1[\s]*$' found in the following lines: 16: gpgcheck=1 24: gpgcheck=1 32: gpgcheck=1 40: gpgcheck=1 /etc/yum.repos.d/CentOS-Vault.repo - regex '^[\s]*gpgcheck[\s]*=' found - expect '^[\s]*gpgcheck[\s]*=[\s]*1[\s]*$' found in the following lines: 8: gpgcheck=1 15: gpgcheck=1 22: gpgcheck=1 29: gpgcheck=1 36: gpgcheck=1 44: gpgcheck=1 51: gpgcheck=1 58: gpgcheck=1 65: gpgcheck=1 72: gpgcheck=1 80: gpgcheck=1 87: gpgcheck=1 94: gpgcheck=1 101: gpgcheck=1 108: gpgcheck=1 116: gpgcheck=1 123: gpgcheck=1 130: gpgcheck=1 137: gpgcheck=1 144: gpgcheck=1 152: gpgcheck=1 [...] 1.3.2 Ensure filesystem integrity is regularly checked - cronInfoPeriodic checking of the filesystem integrity is needed to detect changes to the filesystem.Rationale: Periodic file checking allows the system administrator to determine on a regular basis if critical files have been changed in an unauthorized fashion. SolutionIf cron will be used to schedule and run aide check Run the following command:# crontab -u root -e Add the following line to the crontab: 0 5 * * * /usr/sbin/aide --check OR if aidecheck.service and aidecheck.timer will be used to schedule and run aide check: Create or edit the file /etc/systemd/system/aidecheck.service and add the following lines: [Unit] Description=Aide Check [Service] Type=simple ExecStart=/usr/sbin/aide --check [Install] WantedBy=multi-user.target Create or edit the file /etc/systemd/system/aidecheck.timer and add the following lines: [Unit] Description=Aide check every day at 5AM [Timer] OnCalendar=*-*-* 05:00:00 Unit=aidecheck.service [Install] WantedBy=multi-user.target Run the following commands: # chown root:root /etc/systemd/system/aidecheck.* # chmod 0644 /etc/systemd/system/aidecheck.* # systemctl daemon-reload # systemctl enable aidecheck.service # systemctl --now enable aidecheck.timer See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa1.4.2 Ensure permissions on bootloader config are configured - user.cfgInfoThe grub configuration file contains information on boot settings and passwords for unlocking boot options. The grub2 configuration is usually grub.cfg. On newer grub2 systems the encrypted bootloader password is contained in user.cfg.If the system uses UEFI, /boot/efi is a vfat filesystem. The vfat filesystem itself doesn't have the concept of permissions but can be mounted under Linux with whatever permissions desired. Rationale: Setting the permissions to read and write for root only prevents non-root users from seeing the boot parameters or changing them. Non-root users who read the boot parameters may be able to identify weaknesses in security upon boot and be able to exploit them. SolutionRun the following commands to set ownership and permissions on your grub configuration file(s):# chown root:root /boot/grub2/grub.cfg # test -f /boot/grub2/user.cfg && chown root:root /boot/grub2/user.cfg # chmod og-rwx /boot/grub2/grub.cfg # test -f /boot/grub2/user.cfg && chmod og-rwx /boot/grub2/user.cfg OR If the system uses UEFI, edit /etc/fstab and add the fmask=0077 option: Example: <device> /boot/efi vfat defaults,umask=0027,fmask=0077,uid=0,gid=0 0 0 Note: This may require a re-boot to enable the change Additional Information: This recommendation is designed around the grub2 bootloader. If LILO or another bootloader is in use in your environment: Enact equivalent settings Replace /boot/grub2/grub.cfg and /boot/grub2/user.cfg with the appropriate boot configuration files for your environment See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa1.4.3 Ensure authentication required for single user mode - emergency.serviceInfoSingle user mode (rescue mode) is used for recovery when the system detects an issue during boot or by manual selection from the bootloader.Note: The systemctl option --fail is synonymous with --job-mode=fail. Using either is acceptable. Rationale: Requiring authentication in single user mode (rescue mode) prevents an unauthorized user from rebooting the system into single user to gain root privileges without credentials. SolutionEdit /usr/lib/systemd/system/rescue.service and /usr/lib/systemd/system/emergency.service and set ExecStart to use /sbin/sulogin or /usr/sbin/sulogin:ExecStart=-/bin/sh -c '/sbin/sulogin; /usr/bin/systemctl --fail --no-block default' See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaCompliant file(s):
/usr/lib/systemd/system/emergency.service - regex '^ExecStart=-/bin/sh -c "(/usr)?/sbin/sulogin; (/usr)?/bin/systemctl --fail --no-block default"' found - expect '^ExecStart=-/bin/sh -c "(/usr)?/sbin/sulogin; (/usr)?/bin/systemctl --fail --no-block default"' found in the following lines: 21: ExecStart=-/bin/sh -c "/usr/sbin/sulogin; /usr/bin/systemctl --fail --no-block default" lab-preventaCompliant file(s):
/usr/lib/systemd/system/emergency.service - regex '^ExecStart=-/bin/sh -c "(/usr)?/sbin/sulogin; (/usr)?/bin/systemctl --fail --no-block default"' found - expect '^ExecStart=-/bin/sh -c "(/usr)?/sbin/sulogin; (/usr)?/bin/systemctl --fail --no-block default"' found in the following lines: 21: ExecStart=-/bin/sh -c "/usr/sbin/sulogin; /usr/bin/systemctl --fail --no-block default" 1.4.3 Ensure authentication required for single user mode - rescue.serviceInfoSingle user mode (rescue mode) is used for recovery when the system detects an issue during boot or by manual selection from the bootloader.Note: The systemctl option --fail is synonymous with --job-mode=fail. Using either is acceptable. Rationale: Requiring authentication in single user mode (rescue mode) prevents an unauthorized user from rebooting the system into single user to gain root privileges without credentials. SolutionEdit /usr/lib/systemd/system/rescue.service and /usr/lib/systemd/system/emergency.service and set ExecStart to use /sbin/sulogin or /usr/sbin/sulogin:ExecStart=-/bin/sh -c '/sbin/sulogin; /usr/bin/systemctl --fail --no-block default' See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaCompliant file(s):
/usr/lib/systemd/system/rescue.service - regex '^ExecStart=-/bin/sh -c "(/usr)?/sbin/sulogin; (/usr)?/bin/systemctl --fail --no-block default"' found - expect '^ExecStart=-/bin/sh -c "(/usr)?/sbin/sulogin; (/usr)?/bin/systemctl --fail --no-block default"' found in the following lines: 21: ExecStart=-/bin/sh -c "/usr/sbin/sulogin; /usr/bin/systemctl --fail --no-block default" lab-preventaCompliant file(s):
/usr/lib/systemd/system/rescue.service - regex '^ExecStart=-/bin/sh -c "(/usr)?/sbin/sulogin; (/usr)?/bin/systemctl --fail --no-block default"' found - expect '^ExecStart=-/bin/sh -c "(/usr)?/sbin/sulogin; (/usr)?/bin/systemctl --fail --no-block default"' found in the following lines: 21: ExecStart=-/bin/sh -c "/usr/sbin/sulogin; /usr/bin/systemctl --fail --no-block default" 1.5.1 Ensure core dumps are restricted - sysctlInfoA core dump is the memory of an executable program. It is generally used to determine why a program aborted. It can also be used to glean confidential information from a core file. The system provides the ability to set a soft limit for core dumps, but this can be overridden by the user.Rationale: Setting a hard limit on core dumps prevents users from overriding the soft variable. If core dumps are required, consider setting limits for user groups (see limits.conf(5) ). In addition, setting the fs.suid_dumpable variable to 0 will prevent setuid programs from dumping core. SolutionAdd the following line to /etc/security/limits.conf or a /etc/security/limits.d/* file:* hard core 0 Set the following parameter in /etc/sysctl.conf or a /etc/sysctl.d/* file: fs.suid_dumpable = 0 Run the following command to set the active kernel parameter: # sysctl -w fs.suid_dumpable=0 If systemd-coredump is installed: edit /etc/systemd/coredump.conf and add/modify the following lines: Storage=none ProcessSizeMax=0 Run the command: systemctl daemon-reload See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sysctl fs.suid_dumpable' returned :
fs.suid_dumpable = 0 lab-preventaThe command '/usr/sbin/sysctl fs.suid_dumpable' returned :
fs.suid_dumpable = 0 1.5.1 Ensure core dumps are restricted - systemd-coredump ProcessSizeMaxInfoA core dump is the memory of an executable program. It is generally used to determine why a program aborted. It can also be used to glean confidential information from a core file. The system provides the ability to set a soft limit for core dumps, but this can be overridden by the user.Rationale: Setting a hard limit on core dumps prevents users from overriding the soft variable. If core dumps are required, consider setting limits for user groups (see limits.conf(5) ). In addition, setting the fs.suid_dumpable variable to 0 will prevent setuid programs from dumping core. SolutionAdd the following line to /etc/security/limits.conf or a /etc/security/limits.d/* file:* hard core 0 Set the following parameter in /etc/sysctl.conf or a /etc/sysctl.d/* file: fs.suid_dumpable = 0 Run the following command to set the active kernel parameter: # sysctl -w fs.suid_dumpable=0 If systemd-coredump is installed: edit /etc/systemd/coredump.conf and add/modify the following lines: Storage=none ProcessSizeMax=0 Run the command: systemctl daemon-reload See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa1.5.1 Ensure core dumps are restricted - systemd-coredump StorageInfoA core dump is the memory of an executable program. It is generally used to determine why a program aborted. It can also be used to glean confidential information from a core file. The system provides the ability to set a soft limit for core dumps, but this can be overridden by the user.Rationale: Setting a hard limit on core dumps prevents users from overriding the soft variable. If core dumps are required, consider setting limits for user groups (see limits.conf(5) ). In addition, setting the fs.suid_dumpable variable to 0 will prevent setuid programs from dumping core. SolutionAdd the following line to /etc/security/limits.conf or a /etc/security/limits.d/* file:* hard core 0 Set the following parameter in /etc/sysctl.conf or a /etc/sysctl.d/* file: fs.suid_dumpable = 0 Run the following command to set the active kernel parameter: # sysctl -w fs.suid_dumpable=0 If systemd-coredump is installed: edit /etc/systemd/coredump.conf and add/modify the following lines: Storage=none ProcessSizeMax=0 Run the command: systemctl daemon-reload See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa1.5.2 Ensure XD/NX support is enabledInfoRecent processors in the x86 family support the ability to prevent code execution on a per memory page basis. Generically and on AMD processors, this ability is called No Execute (NX), while on Intel processors it is called Execute Disable (XD). This ability can help prevent exploitation of buffer overflow vulnerabilities and should be activated whenever possible. Extra steps must be taken to ensure that this protection is enabled, particularly on 32-bit x86 systems. Other processors, such as Itanium and POWER, have included such support since inception and the standard kernel for those platforms supports the feature.Rationale: Enabling any feature that can protect against buffer overflow attacks enhances the security of the system. Note: Ensure your system supports the XD or NX bit and has PAE support before implementing this recommendation as this may prevent it from booting if these are not supported by your hardware. SolutionOn 32 bit systems install a kernel with PAE support, no installation is required on 64 bit systems:If necessary configure your bootloader to load the new kernel and reboot the system. You may need to enable NX or XD support in your bios. See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/journalctl | /bin/grep 'protection:\s*active'' returned :
Oct 23 12:28:54 dng.local kernel: NX (Execute Disable) protection: active lab-preventaThe command '/usr/bin/journalctl | /bin/grep 'protection:\s*active'' returned :
Oct 23 12:28:54 dng.local kernel: NX (Execute Disable) protection: active 1.5.3 Ensure address space layout randomization (ASLR) is enabled - sysctlInfoAddress space layout randomization (ASLR) is an exploit mitigation technique which randomly arranges the address space of key data areas of a process.Rationale: Randomly placing virtual memory regions will make it difficult to write memory page exploits as the memory placement will be consistently shifting. SolutionSet the following parameter in /etc/sysctl.conf or a /etc/sysctl.d/* file:kernel.randomize_va_space = 2 Run the following command to set the active kernel parameter: # sysctl -w kernel.randomize_va_space=2 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sysctl kernel.randomize_va_space' returned :
kernel.randomize_va_space = 2 lab-preventaThe command '/usr/sbin/sysctl kernel.randomize_va_space' returned :
kernel.randomize_va_space = 2 1.5.4 Ensure prelink is not installedInfoprelink is a program that modifies ELF shared libraries and ELF dynamically linked binaries in such a way that the time needed for the dynamic linker to perform relocations at startup significantly decreases.Rationale: The prelinking feature can interfere with the operation of AIDE, because it changes binaries. Prelinking can also increase the vulnerability of the system if a malicious user is able to compromise a common library such as libc. SolutionRun the following command to restore binaries to normal:# prelink -ua Run the following command to uninstall prelink: # yum remove prelink See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe package 'prelink-0.0.0-0' is not installed
lab-preventaThe package 'prelink-0.0.0-0' is not installed
1.6.1.1 Ensure SELinux is installedInfoSELinux provides Mandatory Access Control.Rationale: Without a Mandatory Access Control system installed only the default Discretionary Access Control system will be available. SolutionRun the following command to install SELinux:# yum install libselinux See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe local RPM is newer than libselinux-0.0.0-0 (libselinux-2.5-15.el7)
lab-preventaThe local RPM is newer than libselinux-0.0.0-0 (libselinux-2.5-15.el7)
1.6.1.2 Ensure SELinux is not disabled in bootloader configurationInfoConfigure SELINUX to be enabled at boot time and verify that it has not been overwritten by the grub boot parameters.Note: This recommendation is designed around the grub 2 bootloader, if LILO or another bootloader is in use in your environment enact equivalent settings. Rationale: SELinux must be enabled at boot time in your grub configuration to ensure that the controls it provides are not overridden. SolutionEdit /etc/default/grub and remove all instances of selinux=0 and enforcing=0 from all CMDLINE_LINUX parameters:GRUB_CMDLINE_LINUX_DEFAULT='quiet' GRUB_CMDLINE_LINUX='' Run the following command to update the grub2 configuration: # grub2-mkconfig -o /boot/grub2/grub.cfg See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/grep '^s*linux' /boot/grub2/grub.cfg | /usr/bin/grep -E '(selinux=0|enforcing=0)' | /usr/bin/awk '{print} END {if (NR == 0) print "none"}'' returned :
none lab-preventaThe command '/usr/bin/grep '^s*linux' /boot/grub2/grub.cfg | /usr/bin/grep -E '(selinux=0|enforcing=0)' | /usr/bin/awk '{print} END {if (NR == 0) print "none"}'' returned :
none 1.6.1.3 Ensure SELinux policy is configured - /etc/selinux/configInfoConfigure SELinux to meet or exceed the default targeted policy, which constrains daemons and system software only.Note: If your organization requires stricter policies, ensure that they are set in the /etc/selinux/config file. Rationale: Security configuration requirements vary from site to site. Some sites may mandate a policy that is stricter than the default policy, which is perfectly acceptable. This item is intended to ensure that at least the default recommendations are met. SolutionEdit the /etc/selinux/config file to set the SELINUXTYPE parameter:SELINUXTYPE=targeted See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaCompliant file(s):
/etc/selinux/config - regex '^[\s]*[sS][eE][lL][iI][nN][uU][xX][tT][yY][pP][eE][\s]*=' found - expect '^[\s]*[sS][eE][lL][iI][nN][uU][xX][tT][yY][pP][eE][\s]*=[\s]*[Tt][Aa][Rr][Gg][Ee][Tt][Ee][Dd][\s]*$' found in the following lines: 12: SELINUXTYPE=targeted lab-preventaCompliant file(s):
/etc/selinux/config - regex '^[\s]*[sS][eE][lL][iI][nN][uU][xX][tT][yY][pP][eE][\s]*=' found - expect '^[\s]*[sS][eE][lL][iI][nN][uU][xX][tT][yY][pP][eE][\s]*=[\s]*[Tt][Aa][Rr][Gg][Ee][Tt][Ee][Dd][\s]*$' found in the following lines: 12: SELINUXTYPE=targeted 1.6.1.3 Ensure SELinux policy is configured - sestatusInfoConfigure SELinux to meet or exceed the default targeted policy, which constrains daemons and system software only.Note: If your organization requires stricter policies, ensure that they are set in the /etc/selinux/config file. Rationale: Security configuration requirements vary from site to site. Some sites may mandate a policy that is stricter than the default policy, which is perfectly acceptable. This item is intended to ensure that at least the default recommendations are met. SolutionEdit the /etc/selinux/config file to set the SELINUXTYPE parameter:SELINUXTYPE=targeted See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sestatus' returned :
SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Max kernel policy version: 31 lab-preventaThe command '/usr/sbin/sestatus' returned :
SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Max kernel policy version: 31 1.6.1.4 Ensure the SELinux mode is enforcing or permissive - /etc/selinux/configInfoSELinux can run in one of three modes: disabled, permissive, or enforcing:Enforcing - Is the default, and recommended, mode of operation; in enforcing mode SELinux operates normally, enforcing the loaded security policy on the entire system. Permissive - The system acts as if SELinux is enforcing the loaded security policy, including labeling objects and emitting access denial entries in the logs, but it does not actually deny any operations. While not recommended for production systems, permissive mode can be helpful for SELinux policy development. Disabled - Is strongly discouraged; not only does the system avoid enforcing the SELinux policy, it also avoids labeling any persistent objects such as files, making it difficult to enable SELinux in the future Note: you can set individual domains to permissive mode while the system runs in enforcing mode. For example, to make the httpd_t domain permissive: # semanage permissive -a httpd_t Rationale: Running SELinux in disabled mode is strongly discouraged; not only does the system avoid enforcing the SELinux policy, it also avoids labeling any persistent objects such as files, making it difficult to enable SELinux in the future. SolutionRun one of the following commands to set SELinux's running mode:To set SELinux mode to Enforcing: # setenforce 1 OR To set SELinux mode to Permissive: # setenforce 0 Edit the /etc/selinux/config file to set the SELINUX parameter: For Enforcing mode: SELINUX=enforcing OR For Permissive mode: SELINUX=permissive See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaCompliant file(s):
/etc/selinux/config - regex '^[\s]*[sS][eE][lL][iI][nN][uU][xX][\s]*=' found - expect '^[\s]*[sS][eE][lL][iI][nN][uU][xX][\s]*=[\s]*([eE][nN][fF][oO][rR][cC][iI][nN][gG]|[pP][eE][rR][mM][iI][sS][sS][iI][vV][eE])[\s]*$' found in the following lines: 7: SELINUX=enforcing lab-preventaCompliant file(s):
/etc/selinux/config - regex '^[\s]*[sS][eE][lL][iI][nN][uU][xX][\s]*=' found - expect '^[\s]*[sS][eE][lL][iI][nN][uU][xX][\s]*=[\s]*([eE][nN][fF][oO][rR][cC][iI][nN][gG]|[pP][eE][rR][mM][iI][sS][sS][iI][vV][eE])[\s]*$' found in the following lines: 7: SELINUX=enforcing 1.6.1.4 Ensure the SELinux mode is enforcing or permissive - getenforceInfoSELinux can run in one of three modes: disabled, permissive, or enforcing:Enforcing - Is the default, and recommended, mode of operation; in enforcing mode SELinux operates normally, enforcing the loaded security policy on the entire system. Permissive - The system acts as if SELinux is enforcing the loaded security policy, including labeling objects and emitting access denial entries in the logs, but it does not actually deny any operations. While not recommended for production systems, permissive mode can be helpful for SELinux policy development. Disabled - Is strongly discouraged; not only does the system avoid enforcing the SELinux policy, it also avoids labeling any persistent objects such as files, making it difficult to enable SELinux in the future Note: you can set individual domains to permissive mode while the system runs in enforcing mode. For example, to make the httpd_t domain permissive: # semanage permissive -a httpd_t Rationale: Running SELinux in disabled mode is strongly discouraged; not only does the system avoid enforcing the SELinux policy, it also avoids labeling any persistent objects such as files, making it difficult to enable SELinux in the future. SolutionRun one of the following commands to set SELinux's running mode:To set SELinux mode to Enforcing: # setenforce 1 OR To set SELinux mode to Permissive: # setenforce 0 Edit the /etc/selinux/config file to set the SELINUX parameter: For Enforcing mode: SELINUX=enforcing OR For Permissive mode: SELINUX=permissive See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/getenforce' returned :
Enforcing lab-preventaThe command '/usr/sbin/getenforce' returned :
Enforcing 1.6.1.7 Ensure SETroubleshoot is not installedInfoThe SETroubleshoot service notifies desktop users of SELinux denials through a user-friendly interface. The service provides important information around configuration errors, unauthorized intrusions, and other potential errors.Rationale: The SETroubleshoot service is an unnecessary daemon to have running on a server, especially if X Windows is disabled. SolutionRun the following command to Uninstall setroubleshoot:# yum remove setroubleshoot See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe package 'setroubleshoot-0.0.0-0' is not installed
1.6.1.8 Ensure the MCS Translation Service (mcstrans) is not installedInfoThe mcstransd daemon provides category label information to client processes requesting information. The label translations are defined in /etc/selinux/targeted/setrans.confRationale: Since this service is not used very often, remove it to reduce the amount of potentially vulnerable code running on the system. SolutionRun the following command to uninstall mcstrans:# yum remove mcstrans See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe package 'mcstrans-0.0.0-0' is not installed
lab-preventaThe package 'mcstrans-0.0.0-0' is not installed
1.7.1 Ensure message of the day is configured properly - mrsvInfoThe contents of the /etc/motd file are displayed to users after login and function as a message of the day for authenticated users.Unix-based systems have typically displayed information about the OS release and patch level upon logging in to the system. This information can be useful to developers who are developing software for a particular OS platform. If mingetty(8) supports the following options, they display operating system information: m - machine architecture r - operating system release s - operating system name v - operating system version Rationale: Warning messages inform users who are attempting to login to the system of their legal status regarding the system and must include the name of the organization that owns the system and any monitoring policies that are in place. Displaying OS and patch level information in login banners also has the side effect of providing detailed system information to attackers attempting to target specific exploits of a system. Authorized users can easily get this information by running the ' uname -a ' command once they have logged in. SolutionEdit the /etc/motd file with the appropriate contents according to your site policy, remove any instances of m , r , s , v or references to the OS platform OR If the motd is not used, this file can be removed.Run the following command to remove the motd file: # rm /etc/motd See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaNo matching files were found
lab-preventaNo matching files were found
1.7.4 Ensure permissions on /etc/motd are configuredInfoThe contents of the /etc/motd file are displayed to users after login and function as a message of the day for authenticated users.Rationale: If the /etc/motd file does not have the correct ownership it could be modified by unauthorized users with incorrect or misleading information. SolutionRun the following commands to set permissions on /etc/motd :# chown root:root /etc/motd # chmod u-x,go-wx /etc/motd See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe file /etc/motd with fmode owner: root group: root mode: 0644 uid: 0 gid: 0 uneven permissions : FALSE is compliant with the policy value
/etc/motd lab-preventaThe file /etc/motd with fmode owner: root group: root mode: 0644 uid: 0 gid: 0 uneven permissions : FALSE is compliant with the policy value
/etc/motd 1.7.5 Ensure permissions on /etc/issue are configuredInfoThe contents of the /etc/issue file are displayed to users prior to login for local terminals.Rationale: If the /etc/issue file does not have the correct ownership it could be modified by unauthorized users with incorrect or misleading information. SolutionRun the following commands to set permissions on /etc/issue :# chown root:root /etc/issue # chmod u-x,go-wx /etc/issue See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe file /etc/issue with fmode owner: root group: root mode: 0644 uid: 0 gid: 0 uneven permissions : FALSE is compliant with the policy value
/etc/issue lab-preventaThe file /etc/issue with fmode owner: root group: root mode: 0644 uid: 0 gid: 0 uneven permissions : FALSE is compliant with the policy value
/etc/issue 1.7.6 Ensure permissions on /etc/issue.net are configuredInfoThe contents of the /etc/issue.net file are displayed to users prior to login for remote connections from configured services.Rationale: If the /etc/issue.net file does not have the correct ownership it could be modified by unauthorized users with incorrect or misleading information. SolutionRun the following commands to set permissions on /etc/issue.net :# chown root:root /etc/issue.net # chmod u-x,go-wx /etc/issue.net See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe file /etc/issue.net with fmode owner: root group: root mode: 0644 uid: 0 gid: 0 uneven permissions : FALSE is compliant with the policy value
/etc/issue.net lab-preventaThe file /etc/issue.net with fmode owner: root group: root mode: 0644 uid: 0 gid: 0 uneven permissions : FALSE is compliant with the policy value
/etc/issue.net 1.8.2 Ensure GDM login banner is configured - banner message enabledInfoGDM is the GNOME Display Manager which handles graphical login for GNOME based systems.Rationale: Warning messages inform users who are attempting to login to the system of their legal status regarding the system and must include the name of the organization that owns the system and any monitoring policies that are in place. Note: If a graphical login is not required, it should be removed to reduce the attack surface of the system. SolutionEdit or create the file /etc/dconf/profile/gdm and add the following:user-db:user system-db:gdm file-db:/usr/share/gdm/greeter-dconf-defaults Edit or create the file /etc/dconf/db/gdm.d/ and add the following: (This is typically /etc/dconf/db/gdm.d/01-banner-message) [org/gnome/login-screen] banner-message-enable=true banner-message-text='<banner message>' Example Banner Text: 'Authorized users only. All activity may be monitored and reported.' Run the following command to update the system databases: # dconf update Additional Information: Additional options and sections may appear in the /etc/dconf/db/gdm.d/01-banner-message file. If a different GUI login service is in use and required on the system, consult your documentation to disable displaying the last logged on user and apply an equivalent banner. See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa1.8.2 Ensure GDM login banner is configured - banner message textInfoGDM is the GNOME Display Manager which handles graphical login for GNOME based systems.Rationale: Warning messages inform users who are attempting to login to the system of their legal status regarding the system and must include the name of the organization that owns the system and any monitoring policies that are in place. Note: If a graphical login is not required, it should be removed to reduce the attack surface of the system. SolutionEdit or create the file /etc/dconf/profile/gdm and add the following:user-db:user system-db:gdm file-db:/usr/share/gdm/greeter-dconf-defaults Edit or create the file /etc/dconf/db/gdm.d/ and add the following: (This is typically /etc/dconf/db/gdm.d/01-banner-message) [org/gnome/login-screen] banner-message-enable=true banner-message-text='<banner message>' Example Banner Text: 'Authorized users only. All activity may be monitored and reported.' Run the following command to update the system databases: # dconf update Additional Information: Additional options and sections may appear in the /etc/dconf/db/gdm.d/01-banner-message file. If a different GUI login service is in use and required on the system, consult your documentation to disable displaying the last logged on user and apply an equivalent banner. See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa1.8.2 Ensure GDM login banner is configured - file-dbInfoGDM is the GNOME Display Manager which handles graphical login for GNOME based systems.Rationale: Warning messages inform users who are attempting to login to the system of their legal status regarding the system and must include the name of the organization that owns the system and any monitoring policies that are in place. Note: If a graphical login is not required, it should be removed to reduce the attack surface of the system. SolutionEdit or create the file /etc/dconf/profile/gdm and add the following:user-db:user system-db:gdm file-db:/usr/share/gdm/greeter-dconf-defaults Edit or create the file /etc/dconf/db/gdm.d/ and add the following: (This is typically /etc/dconf/db/gdm.d/01-banner-message) [org/gnome/login-screen] banner-message-enable=true banner-message-text='<banner message>' Example Banner Text: 'Authorized users only. All activity may be monitored and reported.' Run the following command to update the system databases: # dconf update Additional Information: Additional options and sections may appear in the /etc/dconf/db/gdm.d/01-banner-message file. If a different GUI login service is in use and required on the system, consult your documentation to disable displaying the last logged on user and apply an equivalent banner. See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa1.8.2 Ensure GDM login banner is configured - system-db:gdmInfoGDM is the GNOME Display Manager which handles graphical login for GNOME based systems.Rationale: Warning messages inform users who are attempting to login to the system of their legal status regarding the system and must include the name of the organization that owns the system and any monitoring policies that are in place. Note: If a graphical login is not required, it should be removed to reduce the attack surface of the system. SolutionEdit or create the file /etc/dconf/profile/gdm and add the following:user-db:user system-db:gdm file-db:/usr/share/gdm/greeter-dconf-defaults Edit or create the file /etc/dconf/db/gdm.d/ and add the following: (This is typically /etc/dconf/db/gdm.d/01-banner-message) [org/gnome/login-screen] banner-message-enable=true banner-message-text='<banner message>' Example Banner Text: 'Authorized users only. All activity may be monitored and reported.' Run the following command to update the system databases: # dconf update Additional Information: Additional options and sections may appear in the /etc/dconf/db/gdm.d/01-banner-message file. If a different GUI login service is in use and required on the system, consult your documentation to disable displaying the last logged on user and apply an equivalent banner. See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa1.8.2 Ensure GDM login banner is configured - user-db:userInfoGDM is the GNOME Display Manager which handles graphical login for GNOME based systems.Rationale: Warning messages inform users who are attempting to login to the system of their legal status regarding the system and must include the name of the organization that owns the system and any monitoring policies that are in place. Note: If a graphical login is not required, it should be removed to reduce the attack surface of the system. SolutionEdit or create the file /etc/dconf/profile/gdm and add the following:user-db:user system-db:gdm file-db:/usr/share/gdm/greeter-dconf-defaults Edit or create the file /etc/dconf/db/gdm.d/ and add the following: (This is typically /etc/dconf/db/gdm.d/01-banner-message) [org/gnome/login-screen] banner-message-enable=true banner-message-text='<banner message>' Example Banner Text: 'Authorized users only. All activity may be monitored and reported.' Run the following command to update the system databases: # dconf update Additional Information: Additional options and sections may appear in the /etc/dconf/db/gdm.d/01-banner-message file. If a different GUI login service is in use and required on the system, consult your documentation to disable displaying the last logged on user and apply an equivalent banner. See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa1.8.3 Ensure last logged in user display is disabled - disable user listInfoGDM is the GNOME Display Manager which handles graphical login for GNOME based systems.Rationale: Displaying the last logged in user eliminates half of the Userid/Password equation that an unauthorized person would need to log on. Warning messages inform users who are attempting to login to the system of their legal status regarding the system and must include the name of the organization that owns the system and any monitoring policies that are in place. Notes: If a graphical login is not required, it should be removed to reduce the attack surface of the system. If a different GUI login service is in use and required on the system, consult your documentation to disable displaying the last logged on user SolutionEdit or create the file /etc/dconf/profile/gdm and add the following:user-db:user system-db:gdm file-db:/usr/share/gdm/greeter-dconf-defaults Edit or create the file /etc/dconf/db/gdm.d/ and add the following: (This is typically /etc/dconf/db/gdm.d/00-login-screen) [org/gnome/login-screen] # Do not show the user list disable-user-list=true Run the following command to update the system databases: # dconf update See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa1.8.3 Ensure last logged in user display is disabled - file-dbInfoGDM is the GNOME Display Manager which handles graphical login for GNOME based systems.Rationale: Displaying the last logged in user eliminates half of the Userid/Password equation that an unauthorized person would need to log on. Warning messages inform users who are attempting to login to the system of their legal status regarding the system and must include the name of the organization that owns the system and any monitoring policies that are in place. Notes: If a graphical login is not required, it should be removed to reduce the attack surface of the system. If a different GUI login service is in use and required on the system, consult your documentation to disable displaying the last logged on user SolutionEdit or create the file /etc/dconf/profile/gdm and add the following:user-db:user system-db:gdm file-db:/usr/share/gdm/greeter-dconf-defaults Edit or create the file /etc/dconf/db/gdm.d/ and add the following: (This is typically /etc/dconf/db/gdm.d/00-login-screen) [org/gnome/login-screen] # Do not show the user list disable-user-list=true Run the following command to update the system databases: # dconf update See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa1.8.3 Ensure last logged in user display is disabled - system-db:gdmInfoGDM is the GNOME Display Manager which handles graphical login for GNOME based systems.Rationale: Displaying the last logged in user eliminates half of the Userid/Password equation that an unauthorized person would need to log on. Warning messages inform users who are attempting to login to the system of their legal status regarding the system and must include the name of the organization that owns the system and any monitoring policies that are in place. Notes: If a graphical login is not required, it should be removed to reduce the attack surface of the system. If a different GUI login service is in use and required on the system, consult your documentation to disable displaying the last logged on user SolutionEdit or create the file /etc/dconf/profile/gdm and add the following:user-db:user system-db:gdm file-db:/usr/share/gdm/greeter-dconf-defaults Edit or create the file /etc/dconf/db/gdm.d/ and add the following: (This is typically /etc/dconf/db/gdm.d/00-login-screen) [org/gnome/login-screen] # Do not show the user list disable-user-list=true Run the following command to update the system databases: # dconf update See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa1.8.3 Ensure last logged in user display is disabled - user-db:userInfoGDM is the GNOME Display Manager which handles graphical login for GNOME based systems.Rationale: Displaying the last logged in user eliminates half of the Userid/Password equation that an unauthorized person would need to log on. Warning messages inform users who are attempting to login to the system of their legal status regarding the system and must include the name of the organization that owns the system and any monitoring policies that are in place. Notes: If a graphical login is not required, it should be removed to reduce the attack surface of the system. If a different GUI login service is in use and required on the system, consult your documentation to disable displaying the last logged on user SolutionEdit or create the file /etc/dconf/profile/gdm and add the following:user-db:user system-db:gdm file-db:/usr/share/gdm/greeter-dconf-defaults Edit or create the file /etc/dconf/db/gdm.d/ and add the following: (This is typically /etc/dconf/db/gdm.d/00-login-screen) [org/gnome/login-screen] # Do not show the user list disable-user-list=true Run the following command to update the system databases: # dconf update See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa1.8.4 Ensure XDCMP is not enabledInfoX Display Manager Control Protocol (XDMCP) is designed to provide authenticated access to display management services for remote displaysRationale: XDMCP is inherently insecure. XDMCP is not a ciphered protocol. This may allow an attacker to capture keystrokes entered by a user XDMCP is vulnerable to man-in-the-middle attacks. This may allow an attacker to steal the credentials of legitimate users by impersonating the XDMCP server. SolutionEdit the file /etc/gdm/custom.conf and remove the lineEnable=true Default Value: false (This is denoted by no Enabled= entry in the file /etc/gdm/custom.conf in the [xdmcp] section See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa2.1.1 Ensure xinetd is not installedInfoThe eXtended InterNET Daemon ( xinetd ) is an open source super daemon that replaced the original inetd daemon. The xinetd daemon listens for well known services and dispatches the appropriate daemon to properly respond to service requests.Rationale: If there are no xinetd services required, it is recommended that the package be removed to reduce the attack surface are of the system. Note: If an xinetd service or services are required, ensure that any xinetd service not required is stopped and disabled SolutionRun the following command to remove xinetd:# yum remove xinetd See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe package 'xinetd-0.0.0-0' is not installed
lab-preventaThe package 'xinetd-0.0.0-0' is not installed
2.2.1.2 Ensure chrony is configured - NTP serverInfochrony is a daemon which implements the Network Time Protocol (NTP) and is designed to synchronize system clocks across a variety of systems and use a source that is highly accurate. More information on chrony can be found at http://chrony.tuxfamily.org/. chrony can be configured to be a client and/or a server.Rationale: If chrony is in use on the system proper configuration is vital to ensuring time synchronization is working properly. Note: This recommendation only applies if chrony is in use on the system. SolutionAdd or edit server or pool lines to /etc/chrony.conf as appropriate:server <remote-server> Add or edit the OPTIONS in /etc/sysconfig/chronyd to include '-u chrony': OPTIONS='-u chrony' See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa2.2.1.2 Ensure chrony is configured - OPTIONSInfochrony is a daemon which implements the Network Time Protocol (NTP) and is designed to synchronize system clocks across a variety of systems and use a source that is highly accurate. More information on chrony can be found at http://chrony.tuxfamily.org/. chrony can be configured to be a client and/or a server.Rationale: If chrony is in use on the system proper configuration is vital to ensuring time synchronization is working properly. Note: This recommendation only applies if chrony is in use on the system. SolutionAdd or edit server or pool lines to /etc/chrony.conf as appropriate:server <remote-server> Add or edit the OPTIONS in /etc/sysconfig/chronyd to include '-u chrony': OPTIONS='-u chrony' See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa2.2.1.3 Ensure ntp is configured - -u ntp:ntpInfontp is a daemon which implements the Network Time Protocol (NTP). It is designed to synchronize system clocks across a variety of systems and use a source that is highly accurate. More information on NTP can be found at http://www.ntp.org. ntp can be configured to be a client and/or a server.Note: This recommendation only applies if ntp is in use on the system. Rationale: If ntp is in use on the system proper configuration is vital to ensuring time synchronization is working properly. SolutionAdd or edit restrict lines in /etc/ntp.conf to match the following:restrict -4 default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery Add or edit server or pool lines to /etc/ntp.conf as appropriate: server <remote-server> Add or edit the OPTIONS in /etc/sysconfig/ntpd to include '-u ntp:ntp': OPTIONS='-u ntp:ntp' Reload the systemd daemon: systemctl daemon-reload Enable and start the ntp service: systemctl --now enable ntpd See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa2.2.1.3 Ensure ntp is configured - restrict -4Infontp is a daemon which implements the Network Time Protocol (NTP). It is designed to synchronize system clocks across a variety of systems and use a source that is highly accurate. More information on NTP can be found at http://www.ntp.org. ntp can be configured to be a client and/or a server.Note: This recommendation only applies if ntp is in use on the system. Rationale: If ntp is in use on the system proper configuration is vital to ensuring time synchronization is working properly. SolutionAdd or edit restrict lines in /etc/ntp.conf to match the following:restrict -4 default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery Add or edit server or pool lines to /etc/ntp.conf as appropriate: server <remote-server> Add or edit the OPTIONS in /etc/sysconfig/ntpd to include '-u ntp:ntp': OPTIONS='-u ntp:ntp' Reload the systemd daemon: systemctl daemon-reload Enable and start the ntp service: systemctl --now enable ntpd See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa2.2.1.3 Ensure ntp is configured - restrict -6Infontp is a daemon which implements the Network Time Protocol (NTP). It is designed to synchronize system clocks across a variety of systems and use a source that is highly accurate. More information on NTP can be found at http://www.ntp.org. ntp can be configured to be a client and/or a server.Note: This recommendation only applies if ntp is in use on the system. Rationale: If ntp is in use on the system proper configuration is vital to ensuring time synchronization is working properly. SolutionAdd or edit restrict lines in /etc/ntp.conf to match the following:restrict -4 default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery Add or edit server or pool lines to /etc/ntp.conf as appropriate: server <remote-server> Add or edit the OPTIONS in /etc/sysconfig/ntpd to include '-u ntp:ntp': OPTIONS='-u ntp:ntp' Reload the systemd daemon: systemctl daemon-reload Enable and start the ntp service: systemctl --now enable ntpd See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa2.2.1.3 Ensure ntp is configured - serverInfontp is a daemon which implements the Network Time Protocol (NTP). It is designed to synchronize system clocks across a variety of systems and use a source that is highly accurate. More information on NTP can be found at http://www.ntp.org. ntp can be configured to be a client and/or a server.Note: This recommendation only applies if ntp is in use on the system. Rationale: If ntp is in use on the system proper configuration is vital to ensuring time synchronization is working properly. SolutionAdd or edit restrict lines in /etc/ntp.conf to match the following:restrict -4 default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery Add or edit server or pool lines to /etc/ntp.conf as appropriate: server <remote-server> Add or edit the OPTIONS in /etc/sysconfig/ntpd to include '-u ntp:ntp': OPTIONS='-u ntp:ntp' Reload the systemd daemon: systemctl daemon-reload Enable and start the ntp service: systemctl --now enable ntpd See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa2.2.10 Ensure IMAP and POP3 server is not installedInfodovecot is an open source IMAP and POP3 server for Linux based systems.Rationale: Unless POP3 and/or IMAP servers are to be provided by this system, it is recommended that the package be removed to reduce the potential attack surface. Notes: Several IMAP/POP3 servers exist and can use other service names. courier-imap and cyrus-imap are example services that provide a mail server. These and other services should also be audited and the packages removed if not required. SolutionRun the following command to remove dovecot:# yum remove dovecot See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe package 'dovecot-0.0.0-0' is not installed
lab-preventaThe package 'dovecot-0.0.0-0' is not installed
2.2.11 Ensure Samba is not installedInfoThe Samba daemon allows system administrators to configure their Linux systems to share file systems and directories with Windows desktops. Samba will advertise the file systems and directories via the Server Message Block (SMB) protocol. Windows desktop users will be able to mount these directories and file systems as letter drives on their systems.Rationale: If there is no need to mount directories and file systems to Windows systems, then this package can be removed to reduce the potential attack surface. SolutionRun the following command to remove samba:# yum remove samba See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe package 'samba-0.0.0-0' is not installed
lab-preventaThe package 'samba-0.0.0-0' is not installed
2.2.12 Ensure HTTP Proxy Server is not installedInfoSquid is a standard proxy server used in many distributions and environments.Rationale: Unless a system is specifically set up to act as a proxy server, it is recommended that the squid package be removed to reduce the potential attack surface. Note: Several HTTP proxy servers exist. These should be checked and removed unless required. SolutionRun the following command to remove the squid package:# yum remove squid See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe package 'squid-0.0.0-0' is not installed
lab-preventaThe package 'squid-0.0.0-0' is not installed
2.2.13 Ensure net-snmp is not installedInfoSimple Network Management Protocol (SNMP) is a widely used protocol for monitoring the health and welfare of network equipment, computer equipment and devices like UPSs.Net-SNMP is a suite of applications used to implement SNMPv1 (RFC 1157), SNMPv2 (RFCs 1901-1908), and SNMPv3 (RFCs 3411-3418) using both IPv4 and IPv6. Support for SNMPv2 classic (a.k.a. 'SNMPv2 historic' - RFCs 1441-1452) was dropped with the 4.0 release of the UCD-snmp package. The Simple Network Management Protocol (SNMP) server is used to listen for SNMP commands from an SNMP management system, execute the commands or collect the information and then send results back to the requesting system. Rationale: The SNMP server can communicate using SNMPv1, which transmits data in the clear and does not require authentication to execute commands. SNMPv3 replaces the simple/clear text password sharing used in SNMPv2 with more securely encoded parameters. If the the SNMP service is not required, the net-snmp package should be removed to reduce the attack surface of the system. Note: If SNMP is required: The server should be configured for SNMP v3 only. User Authentication and Message Encryption should be configured. If SNMP v2 is absolutely necessary, modify the community strings' values. SolutionRun the following command to remove net-snmpd:# yum remove net-snmp See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa2.2.14 Ensure NIS server is not installedInfoThe ypserv package provides the Network Information Service (NIS). This service, formally known as Yellow Pages, is a client-server directory service protocol for distributing system configuration files. The NIS server is a collection of programs that allow for the distribution of configuration files.Rationale: The NIS service is inherently an insecure system that has been vulnerable to DOS attacks, buffer overflows and has poor authentication for querying NIS maps. NIS generally has been replaced by such protocols as Lightweight Directory Access Protocol (LDAP). It is recommended that the ypserv package be removed, and if required a more secure services be used. SolutionRun the following command to remove ypserv:# yum remove ypserv See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe package 'ypserv-0.0.0-0' is not installed
lab-preventaThe package 'ypserv-0.0.0-0' is not installed
2.2.15 Ensure telnet-server is not installedInfoThe telnet-server package contains the telnet daemon, which accepts connections from users from other systems via the telnet protocol.Rationale: The telnet protocol is insecure and unencrypted. The use of an unencrypted transmission medium could allow a user with access to sniff network traffic the ability to steal credentials. The ssh package provides an encrypted session and stronger security. SolutionRun the following command to remove the telnet-server package:# yum remove telnet-server See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe package 'telnet-server-0.0.0-0' is not installed
lab-preventaThe package 'telnet-server-0.0.0-0' is not installed
2.2.16 Ensure mail transfer agent is configured for local-only modeInfoMail Transfer Agents (MTA), such as sendmail and Postfix, are used to listen for incoming mail and transfer the messages to the appropriate user or mail server. If the system is not intended to be a mail server, it is recommended that the MTA be configured to only process local mail.Rationale: The software for all Mail Transfer Agents is complex and most have a long history of security issues. While it is important to ensure that the system can process local mail messages, it is not necessary to have the MTA's daemon listening on a port unless the server is intended to be a mail server that receives and processes mail from other systems. Notes: This recommendation is designed around the postfix mail server. Depending on your environment you may have an alternative MTA installed such as sendmail. If this is the case consult the documentation for your installed MTA to configure the recommended state. SolutionEdit /etc/postfix/main.cf and add the following line to the RECEIVING MAIL section. If the line already exists, change it to look like the line below:inet_interfaces = loopback-only Run the following command to restart postfix: # systemctl restart postfix See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaCompliant file(s):
/etc/postfix/main.cf - regex '^[\s]*inet_interfaces[\s]*=[\s]*' found - expect '^[\s]*inet_interfaces[\s]*=[\s]*(127.0.0.1|[::1]|loopback-only|localhost|[\s,]?){1,}[\s]*$' found in the following lines: 116: inet_interfaces = localhost lab-preventaCompliant file(s):
/etc/postfix/main.cf - regex '^[\s]*inet_interfaces[\s]*=[\s]*' found - expect '^[\s]*inet_interfaces[\s]*=[\s]*(127.0.0.1|[::1]|loopback-only|localhost|[\s,]?){1,}[\s]*$' found in the following lines: 116: inet_interfaces = localhost 2.2.17 Ensure nfs-utils is not installed or the nfs-server service is maskedInfoThe Network File System (NFS) is one of the first and most widely distributed file systems in the UNIX environment. It provides the ability for systems to mount file systems of other servers through the network.Rationale: If the system does not require network shares, it is recommended that the nfs-utils package be removed to reduce the attack surface of the system. SolutionRun the following command to remove nfs-utils:# yum remove nfs-utils OR If the nfs-package is required as a dependency, run the following command to stop and mask the nfs-server service: # systemctl --now mask nfs-server Additional Information: many of the libvirt packages used by Enterprise Linux virtualization are dependent on the nfs-utils package. If the nfs-package is required as a dependency, the nfs-server should be disabled and masked to reduce the attack surface of the system. See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe package 'nfs-utils-0.0.0-0' is not installed
lab-preventaThe package 'nfs-utils-0.0.0-0' is not installed
2.2.18 Ensure rpcbind is not installed or the rpcbind services are masked - rpcbindInfoThe rpcbind utility maps RPC services to the ports on which they listen. RPC processes notify rpcbind when they start, registering the ports they are listening on and the RPC program numbers they expect to serve. The client system then contacts rpcbind on the server with a particular RPC program number. The rpcbind service redirects the client to the proper port number so it can communicate with the requested servicePortmapper is an RPC service, which always listens on tcp and udp 111, and is used to map other RPC services (such as nfs, nlockmgr, quotad, mountd, etc.) to their corresponding port number on the server. When a remote host makes an RPC call to that server, it first consults with portmap to determine where the RPC server is listening. Rationale: A small request (~82 bytes via UDP) sent to the Portmapper generates a large response (7x to 28x amplification), which makes it a suitable tool for DDoS attacks. If rpcbind is not required, it is recommended that the rpcbind package be removed to reduce the attack surface of the system. SolutionRun the following command to remove nfs-utils:# yum remove rpcbind OR If the rpcbind package is required as a dependency, run the following commands to stop and mask the rpcbind and rpcbind.socket services: # systemctl --now mask rpcbind # systemctl --now mask rpcbind.socket Additional Information: Many of the libvirt packages used by Enterprise Linux virtualization, and the nfs-utils package used for The Network File System (NFS), are dependent on the rpcbind package. If the rpcbind is required as a dependency, the services rpcbind.service and rpcbind.socket should be stopped and masked to reduce the attack surface of the system. See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe package 'rpcbind-0.0.0-0' is not installed
lab-preventaThe package 'rpcbind-0.0.0-0' is not installed
2.2.18 Ensure rpcbind is not installed or the rpcbind services are masked - rpcbind.socketInfoThe rpcbind utility maps RPC services to the ports on which they listen. RPC processes notify rpcbind when they start, registering the ports they are listening on and the RPC program numbers they expect to serve. The client system then contacts rpcbind on the server with a particular RPC program number. The rpcbind service redirects the client to the proper port number so it can communicate with the requested servicePortmapper is an RPC service, which always listens on tcp and udp 111, and is used to map other RPC services (such as nfs, nlockmgr, quotad, mountd, etc.) to their corresponding port number on the server. When a remote host makes an RPC call to that server, it first consults with portmap to determine where the RPC server is listening. Rationale: A small request (~82 bytes via UDP) sent to the Portmapper generates a large response (7x to 28x amplification), which makes it a suitable tool for DDoS attacks. If rpcbind is not required, it is recommended that the rpcbind package be removed to reduce the attack surface of the system. SolutionRun the following command to remove nfs-utils:# yum remove rpcbind OR If the rpcbind package is required as a dependency, run the following commands to stop and mask the rpcbind and rpcbind.socket services: # systemctl --now mask rpcbind # systemctl --now mask rpcbind.socket Additional Information: Many of the libvirt packages used by Enterprise Linux virtualization, and the nfs-utils package used for The Network File System (NFS), are dependent on the rpcbind package. If the rpcbind is required as a dependency, the services rpcbind.service and rpcbind.socket should be stopped and masked to reduce the attack surface of the system. See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe package 'rpcbind-0.0.0-0' is not installed
lab-preventaThe package 'rpcbind-0.0.0-0' is not installed
2.2.19 Ensure rsync is not installed or the rsyncd service is maskedInfoThe rsyncd service can be used to synchronize files between systems over network links.Rationale: Unless required, the rsync package should be removed to reduce the attack surface area of the system. The rsyncd service presents a security risk as it uses unencrypted protocols for communication. Note: If a required dependency exists for the rsync package, but the rsyncd service is not required, the service should be masked. Impact: There are packages that are dependent on the rsync package. If the rsync package is removed, these packages will be removed as well. Before removing the rsync package, review any dependent packages to determine if they are required on the system. If a dependent package is required, mask the rsyncd service and leave the rsync package installed. SolutionRun the following command to remove the rsync package:# yum remove rsync OR Run the following command to mask the rsyncd service: # systemctl --now mask rsyncd See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/systemctl is-enabled rsyncd' returned :
disabled lab-preventaThe command '/usr/bin/systemctl is-enabled rsyncd' returned :
disabled 2.2.2 Ensure X11 Server components are not installedInfoThe X Window System provides a Graphical User Interface (GUI) where users can have multiple windows in which to run programs and various add on. The X Windows system is typically used on workstations where users login, but not on servers where users typically do not login.Rationale: Unless your organization specifically requires graphical login access via X Windows, remove it to reduce the potential attack surface. Impact: Many Linux systems run applications which require a Java runtime. Some Linux Java packages have a dependency on specific X Windows xorg-x11-fonts. One workaround to avoid this dependency is to use the 'headless' Java packages for your specific Java runtime. SolutionRun the following command to remove the X Windows Server packages:# yum remove xorg-x11-server* See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe package 'xorg-x11-server-common-0.0.0-0' is not installed
2.2.3 Ensure Avahi Server is not installed - avahiInfoAvahi is a free zeroconf implementation, including a system for multicast DNS/DNS-SD service discovery. Avahi allows programs to publish and discover services and hosts running on a local network with no specific configuration. For example, a user can plug a computer into a network and Avahi automatically finds printers to print to, files to look at and people to talk to, as well as network services running on the machine.Rationale: Automatic discovery of network services is not normally required for system functionality. It is recommended to remove this package to reduce the potential attack surface. SolutionRun the following commands to stop, mask and remove avahi-autoipd and avahi:# systemctl stop avahi-daemon.socket avahi-daemon.service # yum remove avahi-autoipd avahi See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe package 'avahi-0.0.0-0' is not installed
2.2.3 Ensure Avahi Server is not installed - avahi-autoipdInfoAvahi is a free zeroconf implementation, including a system for multicast DNS/DNS-SD service discovery. Avahi allows programs to publish and discover services and hosts running on a local network with no specific configuration. For example, a user can plug a computer into a network and Avahi automatically finds printers to print to, files to look at and people to talk to, as well as network services running on the machine.Rationale: Automatic discovery of network services is not normally required for system functionality. It is recommended to remove this package to reduce the potential attack surface. SolutionRun the following commands to stop, mask and remove avahi-autoipd and avahi:# systemctl stop avahi-daemon.socket avahi-daemon.service # yum remove avahi-autoipd avahi See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe package 'avahi-autoipd-0.0.0-0' is not installed
2.2.4 Ensure CUPS is not installedInfoThe Common Unix Print System (CUPS) provides the ability to print to both local and network printers. A system running CUPS can also accept print jobs from remote systems and print them to local printers. It also provides a web based remote administration capability.Rationale: If the system does not need to print jobs or accept print jobs from other systems, it is recommended that CUPS be removed to reduce the potential attack surface. Note: Removing CUPS will prevent printing from the system Impact: Disabling CUPS will prevent printing from the system, a common task for workstation systems. SolutionRun the following command to remove cups:# yum remove cups See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe package 'cups-0.0.0-0' is not installed
2.2.5 Ensure DHCP Server is not installedInfoThe Dynamic Host Configuration Protocol (DHCP) is a service that allows machines to be dynamically assigned IP addresses.Rationale: Unless a system is specifically set up to act as a DHCP server, it is recommended that the dhcp package be removed to reduce the potential attack surface. SolutionRun the following command to remove dhcp:# yum remove dhcp See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe package 'dhcp-0.0.0-0' is not installed
lab-preventaThe package 'dhcp-0.0.0-0' is not installed
2.2.6 Ensure LDAP server is not installedInfoThe Lightweight Directory Access Protocol (LDAP) was introduced as a replacement for NIS/YP. It is a service that provides a method for looking up information from a central database.Rationale: If the system will not need to act as an LDAP server, it is recommended that the software be removed to reduce the potential attack surface. SolutionRun the following command to remove openldap-servers:# yum remove openldap-servers See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe package 'openldap-servers-0.0.0-0' is not installed
lab-preventaThe package 'openldap-servers-0.0.0-0' is not installed
2.2.7 Ensure DNS Server is not installedInfoThe Domain Name System (DNS) is a hierarchical naming system that maps names to IP addresses for computers, services and other resources connected to a network.Rationale: Unless a system is specifically designated to act as a DNS server, it is recommended that the package be removed to reduce the potential attack surface. SolutionRun the following command to remove bind:# yum remove bind See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe package 'bind-0.0.0-0' is not installed
lab-preventaThe package 'bind-0.0.0-0' is not installed
2.2.8 Ensure FTP Server is not installedInfoFTP (File Transfer Protocol) is a traditional and widely used standard tool for transferring files between a server and clients over a network, especially where no authentication is necessary (permits anonymous users to connect to a server).Rationale: FTP does not protect the confidentiality of data or authentication credentials. It is recommended SFTP be used if file transfer is required. Unless there is a need to run the system as a FTP server (for example, to allow anonymous downloads), it is recommended that the package be removed to reduce the potential attack surface. Note: Additional FTP servers also exist and should be removed if not required. SolutionRun the following command to remove vsftpd:# yum remove vsftpd See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe package 'vsftpd-0.0.0-0' is not installed
lab-preventaThe package 'vsftpd-0.0.0-0' is not installed
2.2.9 Ensure HTTP server is not installedInfoHTTP or web servers provide the ability to host web site content.Rationale: Unless there is a need to run the system as a web server, it is recommended that the package be removed to reduce the potential attack surface. Notes: Several http servers exist. apache, apache2, lighttpd, and nginx are example packages that provide an HTTP server. These and other packages should also be audited, and removed if not required. SolutionRun the following command to remove httpd:# yum remove httpd See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe package 'httpd-0.0.0-0' is not installed
lab-preventaThe package 'httpd-0.0.0-0' is not installed
2.3.1 Ensure NIS Client is not installedInfoThe Network Information Service (NIS), formerly known as Yellow Pages, is a client-server directory service protocol used to distribute system configuration files. The NIS client ( ypbind ) was used to bind a machine to an NIS server and receive the distributed configuration files.Rationale: The NIS service is inherently an insecure system that has been vulnerable to DOS attacks, buffer overflows and has poor authentication for querying NIS maps. NIS generally has been replaced by such protocols as Lightweight Directory Access Protocol (LDAP). It is recommended that the service be removed. Impact: Many insecure service clients are used as troubleshooting tools and in testing environments. Uninstalling them can inhibit capability to test and troubleshoot. If they are required it is advisable to remove the clients after use to prevent accidental or intentional misuse. SolutionRun the following command to remove the ypbind package:# yum remove ypbind See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe package 'ypbind-0.0.0-0' is not installed
lab-preventaThe package 'ypbind-0.0.0-0' is not installed
2.3.2 Ensure rsh client is not installedInfoThe rsh package contains the client commands for the rsh services.Rationale: These legacy clients contain numerous security exposures and have been replaced with the more secure SSH package. Even if the server is removed, it is best to ensure the clients are also removed to prevent users from inadvertently attempting to use these commands and therefore exposing their credentials. Note that removing the rsh package removes the clients for rsh , rcp and rlogin . Impact: Many insecure service clients are used as troubleshooting tools and in testing environments. Uninstalling them can inhibit capability to test and troubleshoot. If they are required it is advisable to remove the clients after use to prevent accidental or intentional misuse. SolutionRun the following command to remove the rsh package:# yum remove rsh See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe package 'rsh-0.0.0-0' is not installed
lab-preventaThe package 'rsh-0.0.0-0' is not installed
2.3.3 Ensure talk client is not installedInfoThe talk software makes it possible for users to send and receive messages across systems through a terminal session. The talk client, which allows initialization of talk sessions, is installed by default.Rationale: The software presents a security risk as it uses unencrypted protocols for communication. Impact: Many insecure service clients are used as troubleshooting tools and in testing environments. Uninstalling them can inhibit capability to test and troubleshoot. If they are required it is advisable to remove the clients after use to prevent accidental or intentional misuse. SolutionRun the following command to remove the talk package:# yum remove talk See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe package 'talk-0.0.0-0' is not installed
lab-preventaThe package 'talk-0.0.0-0' is not installed
2.3.5 Ensure LDAP client is not installedInfoThe Lightweight Directory Access Protocol (LDAP) was introduced as a replacement for NIS/YP. It is a service that provides a method for looking up information from a central database.Rationale: If the system will not need to act as an LDAP client, it is recommended that the software be removed to reduce the potential attack surface. Impact: Removing the LDAP client will prevent or inhibit using LDAP for authentication in your environment. SolutionRun the following command to remove the openldap-clients package:# yum remove openldap-clients See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe package 'openldap-clients-0.0.0-0' is not installed
lab-preventaThe package 'openldap-clients-0.0.0-0' is not installed
3.1.2 Ensure wireless interfaces are disabledInfoWireless networking is used when wired networks are unavailable.Rationale: If wireless is not to be used, wireless devices should be disabled to reduce the potential attack surface. Impact: Many if not all laptop workstations and some desktop workstations will connect via wireless requiring these interfaces be enabled. NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance. SolutionRun the following script to disable any wireless interfaces:#!/bin/bash if command -v nmcli >/dev/null 2>&1 ; then nmcli radio all off else if [ -n '$(find /sys/class/net/*/ -type d -name wireless)' ]; then mname=$(for driverdir in $(find /sys/class/net/*/ -type d -name wireless | xargs -0 dirname); do basename '$(readlink -f '$driverdir'/device/driver/module)';done | sort -u) for dm in $mname; do echo 'install $dm /bin/true' >> /etc/modprobe.d/disable_wireless.conf done fi fi See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/iw list | /bin/awk '{print} END {if (NR == 0) print "none"}'' returned :
sh: /usr/sbin/iw: No such file or directory none 3.2.1 Ensure IP forwarding is disabled - ipv6 sysctlInfoThe net.ipv4.ip_forward and net.ipv6.conf.all.forwarding flags are used to tell the system whether it can forward packets or not.Rationale: Setting the flags to 0 ensures that a system with multiple interfaces (for example, a hard proxy), will never be able to forward packets, and therefore, never serve as a router. SolutionRun the following commands to restore the default parameters and set the active kernel parameters:# grep -Els '^s*net.ipv4.ip_forwards*=s*1' /etc/sysctl.conf /etc/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /run/sysctl.d/*.conf | while read filename; do sed -ri 's/^s*(net.ipv4.ip_forwards*)(=)(s*S+b).*$/# *REMOVED* 1/' $filename; done; sysctl -w net.ipv4.ip_forward=0; sysctl -w net.ipv4.route.flush=1 # grep -Els '^s*net.ipv6.conf.all.forwardings*=s*1' /etc/sysctl.conf /etc/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /run/sysctl.d/*.conf | while read filename; do sed -ri 's/^s*(net.ipv6.conf.all.forwardings*)(=)(s*S+b).*$/# *REMOVED* 1/' $filename; done; sysctl -w net.ipv6.conf.all.forwarding=0; sysctl -w net.ipv6.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sysctl net.ipv6.conf.all.forwarding' returned :
net.ipv6.conf.all.forwarding = 0 lab-preventaThe command '/usr/sbin/sysctl net.ipv6.conf.all.forwarding' returned :
net.ipv6.conf.all.forwarding = 0 3.3.1 Ensure source routed packets are not accepted - 'net.ipv4.conf.all.accept_source_route = 0'InfoIn networking, source routing allows a sender to partially or fully specify the route packets take through a network. In contrast, non-source routed packets travel a path determined by routers in the network. In some cases, systems may not be routable or reachable from some locations (e.g. private addresses vs. Internet routable), and so source routed packets would need to be used.Rationale: Setting net.ipv4.conf.all.accept_source_route, net.ipv4.conf.default.accept_source_route, net.ipv6.conf.all.accept_source_route and net.ipv6.conf.default.accept_source_route to 0 disables the system from accepting source routed packets. Assume this system was capable of routing packets to Internet routable addresses on one interface and private addresses on another interface. Assume that the private addresses were not routable to the Internet routable addresses and vice versa. Under normal routing circumstances, an attacker from the Internet routable addresses could not use the system as a way to reach the private address systems. If, however, source routed packets were allowed, they could be used to gain access to the private address systems as the route could be specified, rather than rely on routing protocols that did not allow this routing. SolutionSet the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file:net.ipv4.conf.all.accept_source_route = 0 net.ipv4.conf.default.accept_source_route = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv4.conf.all.accept_source_route=0 # sysctl -w net.ipv4.conf.default.accept_source_route=0 # sysctl -w net.ipv4.route.flush=1 IF IPv6 is not disabled: Set the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file: net.ipv6.conf.all.accept_source_route = 0 net.ipv6.conf.default.accept_source_route = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv6.conf.all.accept_source_route=0 # sysctl -w net.ipv6.conf.default.accept_source_route=0 # sysctl -w net.ipv6.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sysctl net.ipv4.conf.all.accept_source_route' returned :
net.ipv4.conf.all.accept_source_route = 0 lab-preventaThe command '/usr/sbin/sysctl net.ipv4.conf.all.accept_source_route' returned :
net.ipv4.conf.all.accept_source_route = 0 3.3.1 Ensure source routed packets are not accepted - 'net.ipv4.conf.default.accept_source_route = 0'InfoIn networking, source routing allows a sender to partially or fully specify the route packets take through a network. In contrast, non-source routed packets travel a path determined by routers in the network. In some cases, systems may not be routable or reachable from some locations (e.g. private addresses vs. Internet routable), and so source routed packets would need to be used.Rationale: Setting net.ipv4.conf.all.accept_source_route, net.ipv4.conf.default.accept_source_route, net.ipv6.conf.all.accept_source_route and net.ipv6.conf.default.accept_source_route to 0 disables the system from accepting source routed packets. Assume this system was capable of routing packets to Internet routable addresses on one interface and private addresses on another interface. Assume that the private addresses were not routable to the Internet routable addresses and vice versa. Under normal routing circumstances, an attacker from the Internet routable addresses could not use the system as a way to reach the private address systems. If, however, source routed packets were allowed, they could be used to gain access to the private address systems as the route could be specified, rather than rely on routing protocols that did not allow this routing. SolutionSet the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file:net.ipv4.conf.all.accept_source_route = 0 net.ipv4.conf.default.accept_source_route = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv4.conf.all.accept_source_route=0 # sysctl -w net.ipv4.conf.default.accept_source_route=0 # sysctl -w net.ipv4.route.flush=1 IF IPv6 is not disabled: Set the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file: net.ipv6.conf.all.accept_source_route = 0 net.ipv6.conf.default.accept_source_route = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv6.conf.all.accept_source_route=0 # sysctl -w net.ipv6.conf.default.accept_source_route=0 # sysctl -w net.ipv6.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sysctl net.ipv4.conf.default.accept_source_route' returned :
net.ipv4.conf.default.accept_source_route = 0 lab-preventaThe command '/usr/sbin/sysctl net.ipv4.conf.default.accept_source_route' returned :
net.ipv4.conf.default.accept_source_route = 0 3.3.1 Ensure source routed packets are not accepted - 'net.ipv6.conf.all.accept_source_route = 0'InfoIn networking, source routing allows a sender to partially or fully specify the route packets take through a network. In contrast, non-source routed packets travel a path determined by routers in the network. In some cases, systems may not be routable or reachable from some locations (e.g. private addresses vs. Internet routable), and so source routed packets would need to be used.Rationale: Setting net.ipv4.conf.all.accept_source_route, net.ipv4.conf.default.accept_source_route, net.ipv6.conf.all.accept_source_route and net.ipv6.conf.default.accept_source_route to 0 disables the system from accepting source routed packets. Assume this system was capable of routing packets to Internet routable addresses on one interface and private addresses on another interface. Assume that the private addresses were not routable to the Internet routable addresses and vice versa. Under normal routing circumstances, an attacker from the Internet routable addresses could not use the system as a way to reach the private address systems. If, however, source routed packets were allowed, they could be used to gain access to the private address systems as the route could be specified, rather than rely on routing protocols that did not allow this routing. SolutionSet the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file:net.ipv4.conf.all.accept_source_route = 0 net.ipv4.conf.default.accept_source_route = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv4.conf.all.accept_source_route=0 # sysctl -w net.ipv4.conf.default.accept_source_route=0 # sysctl -w net.ipv4.route.flush=1 IF IPv6 is not disabled: Set the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file: net.ipv6.conf.all.accept_source_route = 0 net.ipv6.conf.default.accept_source_route = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv6.conf.all.accept_source_route=0 # sysctl -w net.ipv6.conf.default.accept_source_route=0 # sysctl -w net.ipv6.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sysctl net.ipv6.conf.all.accept_source_route' returned :
net.ipv6.conf.all.accept_source_route = 0 lab-preventaThe command '/usr/sbin/sysctl net.ipv6.conf.all.accept_source_route' returned :
net.ipv6.conf.all.accept_source_route = 0 3.3.1 Ensure source routed packets are not accepted - 'net.ipv6.conf.default.accept_source_route = 0'InfoIn networking, source routing allows a sender to partially or fully specify the route packets take through a network. In contrast, non-source routed packets travel a path determined by routers in the network. In some cases, systems may not be routable or reachable from some locations (e.g. private addresses vs. Internet routable), and so source routed packets would need to be used.Rationale: Setting net.ipv4.conf.all.accept_source_route, net.ipv4.conf.default.accept_source_route, net.ipv6.conf.all.accept_source_route and net.ipv6.conf.default.accept_source_route to 0 disables the system from accepting source routed packets. Assume this system was capable of routing packets to Internet routable addresses on one interface and private addresses on another interface. Assume that the private addresses were not routable to the Internet routable addresses and vice versa. Under normal routing circumstances, an attacker from the Internet routable addresses could not use the system as a way to reach the private address systems. If, however, source routed packets were allowed, they could be used to gain access to the private address systems as the route could be specified, rather than rely on routing protocols that did not allow this routing. SolutionSet the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file:net.ipv4.conf.all.accept_source_route = 0 net.ipv4.conf.default.accept_source_route = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv4.conf.all.accept_source_route=0 # sysctl -w net.ipv4.conf.default.accept_source_route=0 # sysctl -w net.ipv4.route.flush=1 IF IPv6 is not disabled: Set the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file: net.ipv6.conf.all.accept_source_route = 0 net.ipv6.conf.default.accept_source_route = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv6.conf.all.accept_source_route=0 # sysctl -w net.ipv6.conf.default.accept_source_route=0 # sysctl -w net.ipv6.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sysctl net.ipv6.conf.default.accept_source_route' returned :
net.ipv6.conf.default.accept_source_route = 0 lab-preventaThe command '/usr/sbin/sysctl net.ipv6.conf.default.accept_source_route' returned :
net.ipv6.conf.default.accept_source_route = 0 3.3.2 Ensure ICMP redirects are not accepted - 'net.ipv4.conf.all.accept_redirects = 0'InfoICMP redirect messages are packets that convey routing information and tell your host (acting as a router) to send packets via an alternate path. It is a way of allowing an outside routing device to update your system routing tables. By setting net.ipv4.conf.all.accept_redirects and net.ipv6.conf.all.accept_redirects to 0, the system will not accept any ICMP redirect messages, and therefore, won't allow outsiders to update the system's routing tables.Rationale: Attackers could use bogus ICMP redirect messages to maliciously alter the system routing tables and get them to send packets to incorrect networks and allow your system packets to be captured. SolutionSet the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file:net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv4.conf.all.accept_redirects=0 # sysctl -w net.ipv4.conf.default.accept_redirects=0 # sysctl -w net.ipv4.route.flush=1 IF IPv6 is not disabled Set the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file: net.ipv6.conf.all.accept_redirects = 0 net.ipv6.conf.default.accept_redirects = 0 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv6.conf.all.accept_redirects=0 # sysctl -w net.ipv6.conf.default.accept_redirects=0 # sysctl -w net.ipv6.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sysctl net.ipv4.conf.all.accept_redirects' returned :
net.ipv4.conf.all.accept_redirects = 0 lab-preventaThe command '/usr/sbin/sysctl net.ipv4.conf.all.accept_redirects' returned :
net.ipv4.conf.all.accept_redirects = 0 3.3.5 Ensure broadcast ICMP requests are ignored - sysctlInfoSetting net.ipv4.icmp_echo_ignore_broadcasts to 1 will cause the system to ignore all ICMP echo and timestamp requests to broadcast and multicast addresses.Rationale: Accepting ICMP echo and timestamp requests with broadcast or multicast destinations for your network could be used to trick your host into starting (or participating) in a Smurf attack. A Smurf attack relies on an attacker sending large amounts of ICMP broadcast messages with a spoofed source address. All hosts receiving this message and responding would send echo-reply messages back to the spoofed address, which is probably not routable. If many hosts respond to the packets, the amount of traffic on the network could be significantly multiplied. SolutionSet the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file:net.ipv4.icmp_echo_ignore_broadcasts = 1 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1 # sysctl -w net.ipv4.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sysctl net.ipv4.icmp_echo_ignore_broadcasts' returned :
net.ipv4.icmp_echo_ignore_broadcasts = 1 lab-preventaThe command '/usr/sbin/sysctl net.ipv4.icmp_echo_ignore_broadcasts' returned :
net.ipv4.icmp_echo_ignore_broadcasts = 1 3.3.6 Ensure bogus ICMP responses are ignored - sysctlInfoSetting icmp_ignore_bogus_error_responses to 1 prevents the kernel from logging bogus responses (RFC-1122 non-compliant) from broadcast reframes, keeping file systems from filling up with useless log messages.Rationale: Some routers (and some attackers) will send responses that violate RFC-1122 and attempt to fill up a log file system with many useless error messages. SolutionSet the following parameter in /etc/sysctl.conf or a /etc/sysctl.d/* file:net.ipv4.icmp_ignore_bogus_error_responses = 1 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv4.icmp_ignore_bogus_error_responses=1 # sysctl -w net.ipv4.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sysctl net.ipv4.icmp_ignore_bogus_error_responses' returned :
net.ipv4.icmp_ignore_bogus_error_responses = 1 lab-preventaThe command '/usr/sbin/sysctl net.ipv4.icmp_ignore_bogus_error_responses' returned :
net.ipv4.icmp_ignore_bogus_error_responses = 1 3.3.7 Ensure Reverse Path Filtering is enabled - 'net.ipv4.conf.all.rp_filter = 1'InfoSetting net.ipv4.conf.all.rp_filter and net.ipv4.conf.default.rp_filter to 1 forces the Linux kernel to utilize reverse path filtering on a received packet to determine if the packet was valid. Essentially, with reverse path filtering, if the return packet does not go out the same interface that the corresponding source packet came from, the packet is dropped (and logged if log_martians is set).Rationale: Setting these flags is a good way to deter attackers from sending your system bogus packets that cannot be responded to. One instance where this feature breaks down is if asymmetrical routing is employed. This would occur when using dynamic routing protocols (bgp, ospf, etc) on your system. If you are using asymmetrical routing on your system, you will not be able to enable this feature without breaking the routing. SolutionSet the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file:net.ipv4.conf.all.rp_filter = 1 net.ipv4.conf.default.rp_filter = 1 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv4.conf.all.rp_filter=1 # sysctl -w net.ipv4.conf.default.rp_filter=1 # sysctl -w net.ipv4.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sysctl net.ipv4.conf.all.rp_filter' returned :
net.ipv4.conf.all.rp_filter = 1 lab-preventaThe command '/usr/sbin/sysctl net.ipv4.conf.all.rp_filter' returned :
net.ipv4.conf.all.rp_filter = 1 3.3.7 Ensure Reverse Path Filtering is enabled - 'net.ipv4.conf.default.rp_filter = 1'InfoSetting net.ipv4.conf.all.rp_filter and net.ipv4.conf.default.rp_filter to 1 forces the Linux kernel to utilize reverse path filtering on a received packet to determine if the packet was valid. Essentially, with reverse path filtering, if the return packet does not go out the same interface that the corresponding source packet came from, the packet is dropped (and logged if log_martians is set).Rationale: Setting these flags is a good way to deter attackers from sending your system bogus packets that cannot be responded to. One instance where this feature breaks down is if asymmetrical routing is employed. This would occur when using dynamic routing protocols (bgp, ospf, etc) on your system. If you are using asymmetrical routing on your system, you will not be able to enable this feature without breaking the routing. SolutionSet the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file:net.ipv4.conf.all.rp_filter = 1 net.ipv4.conf.default.rp_filter = 1 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv4.conf.all.rp_filter=1 # sysctl -w net.ipv4.conf.default.rp_filter=1 # sysctl -w net.ipv4.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sysctl net.ipv4.conf.default.rp_filter' returned :
net.ipv4.conf.default.rp_filter = 1 lab-preventaThe command '/usr/sbin/sysctl net.ipv4.conf.default.rp_filter' returned :
net.ipv4.conf.default.rp_filter = 1 3.3.8 Ensure TCP SYN Cookies is enabled - sysctlInfoWhen tcp_syncookies is set, the kernel will handle TCP SYN packets normally until the half-open connection queue is full, at which time, the SYN cookie functionality kicks in. SYN cookies work by not using the SYN queue at all. Instead, the kernel simply replies to the SYN with a SYN|ACK, but will include a specially crafted TCP sequence number that encodes the source and destination IP address and port number and the time the packet was sent. A legitimate connection would send the ACK packet of the three way handshake with the specially crafted sequence number. This allows the system to verify that it has received a valid response to a SYN cookie and allow the connection, even though there is no corresponding SYN in the queue.Rationale: Attackers use SYN flood attacks to perform a denial of service attacked on a system by sending many SYN packets without completing the three way handshake. This will quickly use up slots in the kernel's half-open connection queue and prevent legitimate connections from succeeding. SYN cookies allow the system to keep accepting valid connections, even if under a denial of service attack. SolutionSet the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file:net.ipv4.tcp_syncookies = 1 Run the following commands to set the active kernel parameters: # sysctl -w net.ipv4.tcp_syncookies=1 # sysctl -w net.ipv4.route.flush=1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sysctl net.ipv4.tcp_syncookies' returned :
net.ipv4.tcp_syncookies = 1 lab-preventaThe command '/usr/sbin/sysctl net.ipv4.tcp_syncookies' returned :
net.ipv4.tcp_syncookies = 1 3.5.1.1 Ensure firewalld is installed - firewalldInfofirewalld is a firewall management tool for Linux operating systems. It provides firewall features by acting as a front-end for the Linux kernel's netfilter framework via the iptables backend or provides firewall features by acting as a front-end for the Linux kernel's netfilter framework via the nftables utility.firewalld replaces iptables as the default firewall management tool. Use the firewalld utility to configure a firewall for less complex firewalls. The utility is easy to use and covers the typical use cases scenario. FirewallD supports both IPv4 and IPv6 networks and can administer separate firewall zones with varying degrees of trust as defined in zone profiles. Note: Starting in v0.6.0, FirewallD added support for acting as a front-end for the Linux kernel's netfilter framework via the nftables userspace utility, acting as an alternative to the nft command line program. Rationale: A firewall utility is required to configure the Linux kernel's netfilter framework via the iptables or nftables back-end. The Linux kernel's netfilter framework host-based firewall can protect against threats originating from within a corporate network to include malicious mobile code and poorly configured software on a host. Note: Only one firewall utility should be installed and configured. FirewallD is dependent on the iptables package. Impact: Changing firewall settings while connected over the network can result in being locked out of the system. SolutionRun the following command to install FirewallD and iptables:# yum install firewalld iptables See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe local RPM is newer than firewalld-0.0.0-0 (firewalld-0.6.3-13.el7_9)
lab-preventaThe local RPM is newer than firewalld-0.0.0-0 (firewalld-0.6.3-13.el7_9)
3.5.1.1 Ensure firewalld is installed - iptablesInfofirewalld is a firewall management tool for Linux operating systems. It provides firewall features by acting as a front-end for the Linux kernel's netfilter framework via the iptables backend or provides firewall features by acting as a front-end for the Linux kernel's netfilter framework via the nftables utility.firewalld replaces iptables as the default firewall management tool. Use the firewalld utility to configure a firewall for less complex firewalls. The utility is easy to use and covers the typical use cases scenario. FirewallD supports both IPv4 and IPv6 networks and can administer separate firewall zones with varying degrees of trust as defined in zone profiles. Note: Starting in v0.6.0, FirewallD added support for acting as a front-end for the Linux kernel's netfilter framework via the nftables userspace utility, acting as an alternative to the nft command line program. Rationale: A firewall utility is required to configure the Linux kernel's netfilter framework via the iptables or nftables back-end. The Linux kernel's netfilter framework host-based firewall can protect against threats originating from within a corporate network to include malicious mobile code and poorly configured software on a host. Note: Only one firewall utility should be installed and configured. FirewallD is dependent on the iptables package. Impact: Changing firewall settings while connected over the network can result in being locked out of the system. SolutionRun the following command to install FirewallD and iptables:# yum install firewalld iptables See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe local RPM is newer than iptables-0.0.0-0 (iptables-1.4.21-35.el7)
lab-preventaThe local RPM is newer than iptables-0.0.0-0 (iptables-1.4.21-35.el7)
3.5.1.2 Ensure iptables-services not installed with firewalldInfoThe iptables-services package contains the iptables.service and ip6tables.service. These services allow for management of the Host Based Firewall provided by the iptables package.Rationale: iptables.service and ip6tables.service are still supported and can be installed with the iptables-services package. Running both firewalld and the services included in the iptables-services package may lead to conflict. Impact: Running both firewalld and iptables/ip6tables service may lead to conflict. SolutionRun the following commands to stop the services included in the iptables-services package and remove the iptables-services package# systemctl stop iptables # systemctl stop ip6tables # yum remove iptables-services See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe package 'iptables-services-0.0.0-0' is not installed
lab-preventaThe package 'iptables-services-0.0.0-0' is not installed
3.5.1.3 Ensure nftables either not installed or masked with firewalld - maskedInfonftables is a subsystem of the Linux kernel providing filtering and classification of network packets/datagrams/frames and is the successor to iptables._Note: Support for using nftables as the back-end for firewalld was added in release v0.6.0. In Fedora 19 Linux derivatives, firewalld utilizes iptables as its back-end by default. Rationale: Running both firewalld and nftables may lead to conflict. Note: firewalld may configured as the front-end to nftables. If this case, nftables should be stopped and masked instead of removed. SolutionRun the following command to remove nftables:# yum remove nftables OR Run the following command to stop and mask nftables' systemctl --now mask nftables See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe package 'nftables-0.0.0-0' is not installed
lab-preventaThe package 'nftables-0.0.0-0' is not installed
3.5.1.3 Ensure nftables either not installed or masked with firewalld - stoppedInfonftables is a subsystem of the Linux kernel providing filtering and classification of network packets/datagrams/frames and is the successor to iptables._Note: Support for using nftables as the back-end for firewalld was added in release v0.6.0. In Fedora 19 Linux derivatives, firewalld utilizes iptables as its back-end by default. Rationale: Running both firewalld and nftables may lead to conflict. Note: firewalld may configured as the front-end to nftables. If this case, nftables should be stopped and masked instead of removed. SolutionRun the following command to remove nftables:# yum remove nftables OR Run the following command to stop and mask nftables' systemctl --now mask nftables See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe package 'nftables-0.0.0-0' is not installed
lab-preventaThe package 'nftables-0.0.0-0' is not installed
3.5.1.4 Ensure firewalld service enabled and running - enabledInfofirewalld.service enables the enforcement of firewall rules configured through firewalldRationale: Ensure that the firewalld.service is enabled and running to enforce firewall rules configured through firewalld Impact: Changing firewall settings while connected over network can result in being locked out of the system. SolutionRun the following command to unmask firewalld# systemctl unmask firewalld Run the following command to enable and start firewalld # systemctl --now enable firewalld See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/systemctl is-enabled firewalld' returned :
enabled lab-preventaThe command '/usr/bin/systemctl is-enabled firewalld' returned :
enabled 3.5.1.4 Ensure firewalld service enabled and running - runningInfofirewalld.service enables the enforcement of firewall rules configured through firewalldRationale: Ensure that the firewalld.service is enabled and running to enforce firewall rules configured through firewalld Impact: Changing firewall settings while connected over network can result in being locked out of the system. SolutionRun the following command to unmask firewalld# systemctl unmask firewalld Run the following command to enable and start firewalld # systemctl --now enable firewalld See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/firewall-cmd --state' returned :
running lab-preventaThe command '/usr/bin/firewall-cmd --state' returned :
running 3.5.1.5 Ensure firewalld default zone is setInfoA firewall zone defines the trust level for a connection, interface or source address binding. This is a one to many relation, which means that a connection, interface or source can only be part of one zone, but a zone can be used for many network connections, interfaces and sources.The default zone is the zone that is used for everything that is not explicitly bound/assigned to another zone. If no zone assigned to a connection, interface or source, only the default zone is used. The default zone is not always listed as being used for an interface or source as it will be used for it either way. This depends on the manager of the interfaces. Connections handled by NetworkManager are listed as NetworkManager requests to add the zone binding for the interface used by the connection. Also interfaces under control of the network service are listed also because the service requests it. Note: A firewalld zone configuration file contains the information for a zone. These are the zone description, services, ports, protocols, icmp-blocks, masquerade, forward-ports and rich language rules in an XML file format. The file name has to be zone_name.xml where length of zone_name is currently limited to 17 chars. NetworkManager binds interfaces to zones automatically Rationale: Because the default zone is the zone that is used for everything that is not explicitly bound/assigned to another zone, it is important for the default zone to set SolutionRun the following command to set the default zone:# firewall-cmd --set-default-zone=<NAME_OF_ZONE> Example: # firewall-cmd --set-default-zone=public See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/firewall-cmd --get-default-zone' returned :
public lab-preventaThe command '/usr/bin/firewall-cmd --get-default-zone' returned :
public 3.5.2.1 Ensure nftables is installedInfonftables provides a new in-kernel packet classification framework that is based on a network-specific Virtual Machine (VM) and a new nft userspace command line tool. nftables reuses the existing Netfilter subsystems such as the existing hook infrastructure, the connection tracking system, NAT, userspace queuing and logging subsystem.Note: nftables is available in Linux kernel 3.13 and newer. Only one firewall utility should be installed and configured. Rationale: nftables is a subsystem of the Linux kernel that can protect against threats originating from within a corporate network to include malicious mobile code and poorly configured software on a host. Impact: Changing firewall settings while connected over the network can result in being locked out of the system. SolutionRun the following command to install nftables# yum install nftables See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.2.10 Ensure nftables service is enabledInfoThe nftables service allows for the loading of nftables rulesets during boot, or starting on the nftables serviceRationale: The nftables service restores the nftables rules from the rules files referenced in the /etc/sysconfig/nftables.conf file during boot or the starting of the nftables service SolutionRun the following command to enable the nftables service:# systemctl enable nftables See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.2.11 Ensure nftables rules are permanentInfonftables is a subsystem of the Linux kernel providing filtering and classification of network packets/datagrams/frames.The nftables service reads the /etc/sysconfig/nftables.conf file for a nftables file or files to include in the nftables ruleset. A nftables ruleset containing the input, forward, and output base chains allow network traffic to be filtered. Rationale: Changes made to nftables ruleset only affect the live system, you will also need to configure the nftables ruleset to apply on boot SolutionEdit the /etc/sysconfig/nftables.conf file and un-comment or add a line with include <Absolute path to nftables rules file> for each nftables file you want included in the nftables ruleset on boot:Example: include '/etc/nftables/nftables.rules' See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.2.2 Ensure firewalld is either not installed or masked with nftables - maskedInfofirewalld (Dynamic Firewall Manager) provides a dynamically managed firewall with support for network/firewall 'zones' to assign a level of trust to a network and its associated connections, interfaces or sources. It has support for IPv4, IPv6, Ethernet bridges and also for IPSet firewall settings. There is a separation of the runtime and permanent configuration options.Rationale: Running both nftables.service and firewalld.service may lead to conflict and unexpected results. SolutionRun the following command to remove firewalld# yum remove firewalld OR Run the following command to stop and mask firewalld # systemctl --now mask firewalld See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.2.2 Ensure firewalld is either not installed or masked with nftables - stoppedInfofirewalld (Dynamic Firewall Manager) provides a dynamically managed firewall with support for network/firewall 'zones' to assign a level of trust to a network and its associated connections, interfaces or sources. It has support for IPv4, IPv6, Ethernet bridges and also for IPSet firewall settings. There is a separation of the runtime and permanent configuration options.Rationale: Running both nftables.service and firewalld.service may lead to conflict and unexpected results. SolutionRun the following command to remove firewalld# yum remove firewalld OR Run the following command to stop and mask firewalld # systemctl --now mask firewalld See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.2.3 Ensure iptables-services not installed with nftablesInfoThe iptables-services package contains the iptables.service and ip6tables.service. These services allow for management of the Host Based Firewall provided by the iptables package.Rationale: iptables.service and ip6tables.service are still supported and can be installed with the iptables-services package. Running both nftables and the services included in the iptables-services package may lead to conflict. SolutionRun the following commands to stop the services included in the iptables-services package and remove the iptables-services package# systemctl stop iptables # systemctl stop ip6tables # yum remove iptables-services See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.2.4 Ensure iptables are flushed with nftables - ip6tablesInfonftables is a replacement for iptables, ip6tables, ebtables and arptablesRationale: It is possible to mix iptables and nftables. However, this increases complexity and also the chance to introduce errors. For simplicity flush out all iptables rules, and ensure it is not loaded SolutionRun the following commands to flush iptables:For iptables: # iptables -F For ip6tables: # ip6tables -F See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.2.4 Ensure iptables are flushed with nftables - iptablesInfonftables is a replacement for iptables, ip6tables, ebtables and arptablesRationale: It is possible to mix iptables and nftables. However, this increases complexity and also the chance to introduce errors. For simplicity flush out all iptables rules, and ensure it is not loaded SolutionRun the following commands to flush iptables:For iptables: # iptables -F For ip6tables: # ip6tables -F See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.2.5 Ensure an nftables table existsInfoTables hold chains. Each table only has one address family and only applies to packets of this family. Tables can have one of five families.Rationale: nftables doesn't have any default tables. Without a table being build, nftables will not filter network traffic. Impact: Adding rules to a running nftables can cause loss of connectivity to the system SolutionRun the following command to create a table in nftables# nft create table inet <table name> Example: # nft create table inet filter See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.2.6 Ensure nftables base chains exist - hook forwardInfoChains are containers for rules. They exist in two kinds, base chains and regular chains. A base chain is an entry point for packets from the networking stack, a regular chain may be used as jump target and is used for better rule organization.Rationale: If a base chain doesn't exist with a hook for input, forward, and delete, packets that would flow through those chains will not be touched by nftables. Impact: If configuring nftables over ssh, creating a base chain with a policy of drop will cause loss of connectivity. Ensure that a rule allowing ssh has been added to the base chain prior to setting the base chain's policy to drop SolutionRun the following command to create the base chains:# nft create chain inet <table name> <base chain name> { type filter hook <(input|forward|output)> priority 0 ; } Example: # nft create chain inet filter input { type filter hook input priority 0 ; } # nft create chain inet filter forward { type filter hook forward priority 0 ; } # nft create chain inet filter output { type filter hook output priority 0 ; } See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.2.6 Ensure nftables base chains exist - hook inputInfoChains are containers for rules. They exist in two kinds, base chains and regular chains. A base chain is an entry point for packets from the networking stack, a regular chain may be used as jump target and is used for better rule organization.Rationale: If a base chain doesn't exist with a hook for input, forward, and delete, packets that would flow through those chains will not be touched by nftables. Impact: If configuring nftables over ssh, creating a base chain with a policy of drop will cause loss of connectivity. Ensure that a rule allowing ssh has been added to the base chain prior to setting the base chain's policy to drop SolutionRun the following command to create the base chains:# nft create chain inet <table name> <base chain name> { type filter hook <(input|forward|output)> priority 0 ; } Example: # nft create chain inet filter input { type filter hook input priority 0 ; } # nft create chain inet filter forward { type filter hook forward priority 0 ; } # nft create chain inet filter output { type filter hook output priority 0 ; } See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.2.6 Ensure nftables base chains exist - hook outputInfoChains are containers for rules. They exist in two kinds, base chains and regular chains. A base chain is an entry point for packets from the networking stack, a regular chain may be used as jump target and is used for better rule organization.Rationale: If a base chain doesn't exist with a hook for input, forward, and delete, packets that would flow through those chains will not be touched by nftables. Impact: If configuring nftables over ssh, creating a base chain with a policy of drop will cause loss of connectivity. Ensure that a rule allowing ssh has been added to the base chain prior to setting the base chain's policy to drop SolutionRun the following command to create the base chains:# nft create chain inet <table name> <base chain name> { type filter hook <(input|forward|output)> priority 0 ; } Example: # nft create chain inet filter input { type filter hook input priority 0 ; } # nft create chain inet filter forward { type filter hook forward priority 0 ; } # nft create chain inet filter output { type filter hook output priority 0 ; } See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.2.7 Ensure nftables loopback traffic is configured - iif loInfoConfigure the loopback interface to accept traffic. Configure all other interfaces to deny traffic to the loopback networkRationale: Loopback traffic is generated between processes on machine and is typically critical to operation of the system. The loopback interface is the only place that loopback network traffic should be seen, all other interfaces should ignore traffic on this network as an anti-spoofing measure. SolutionRun the following commands to implement the loopback rules:# nft add rule inet filter input iif lo accept # nft create rule inet filter input ip saddr 127.0.0.0/8 counter drop IF IPv6 is enabled: Run the following command to implement the IPv6 loopback rules: # nft add rule inet filter input ip6 saddr ::1 counter drop See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.2.7 Ensure nftables loopback traffic is configured - ip saddrInfoConfigure the loopback interface to accept traffic. Configure all other interfaces to deny traffic to the loopback networkRationale: Loopback traffic is generated between processes on machine and is typically critical to operation of the system. The loopback interface is the only place that loopback network traffic should be seen, all other interfaces should ignore traffic on this network as an anti-spoofing measure. SolutionRun the following commands to implement the loopback rules:# nft add rule inet filter input iif lo accept # nft create rule inet filter input ip saddr 127.0.0.0/8 counter drop IF IPv6 is enabled: Run the following command to implement the IPv6 loopback rules: # nft add rule inet filter input ip6 saddr ::1 counter drop See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.2.7 Ensure nftables loopback traffic is configured - ip6 saddrInfoConfigure the loopback interface to accept traffic. Configure all other interfaces to deny traffic to the loopback networkRationale: Loopback traffic is generated between processes on machine and is typically critical to operation of the system. The loopback interface is the only place that loopback network traffic should be seen, all other interfaces should ignore traffic on this network as an anti-spoofing measure. SolutionRun the following commands to implement the loopback rules:# nft add rule inet filter input iif lo accept # nft create rule inet filter input ip saddr 127.0.0.0/8 counter drop IF IPv6 is enabled: Run the following command to implement the IPv6 loopback rules: # nft add rule inet filter input ip6 saddr ::1 counter drop See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.2.8 Ensure nftables outbound and established connections are configured - inputInfoConfigure the firewall rules for new outbound and established connectionsRationale: If rules are not in place for new outbound and established connections, all packets will be dropped by the default policy preventing network usage. SolutionConfigure nftables in accordance with site policy. The following commands will implement a policy to allow all outbound connections and all established connections:# nft add rule inet filter input ip protocol tcp ct state established accept # nft add rule inet filter input ip protocol udp ct state established accept # nft add rule inet filter input ip protocol icmp ct state established accept # nft add rule inet filter output ip protocol tcp ct state new,related,established accept # nft add rule inet filter output ip protocol udp ct state new,related,established accept # nft add rule inet filter output ip protocol icmp ct state new,related,established accept See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.2.8 Ensure nftables outbound and established connections are configured - outputInfoConfigure the firewall rules for new outbound and established connectionsRationale: If rules are not in place for new outbound and established connections, all packets will be dropped by the default policy preventing network usage. SolutionConfigure nftables in accordance with site policy. The following commands will implement a policy to allow all outbound connections and all established connections:# nft add rule inet filter input ip protocol tcp ct state established accept # nft add rule inet filter input ip protocol udp ct state established accept # nft add rule inet filter input ip protocol icmp ct state established accept # nft add rule inet filter output ip protocol tcp ct state new,related,established accept # nft add rule inet filter output ip protocol udp ct state new,related,established accept # nft add rule inet filter output ip protocol icmp ct state new,related,established accept See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.2.9 Ensure nftables default deny firewall policy - forwardInfoBase chain policy is the default verdict that will be applied to packets reaching the end of the chain.Rationale: There are two policies: accept (Default) and drop. If the policy is set to accept, the firewall will accept any packet that is not configured to be denied and the packet will continue traversing the network stack. It is easier to white list acceptable usage than to black list unacceptable usage. Note: Changing firewall settings while connected over the network can result in being locked out of the system. Impact: If configuring nftables over ssh, creating a base chain with a policy of drop will cause loss of connectivity. Ensure that a rule allowing ssh has been added to the base chain prior to setting the base chain's policy to drop SolutionRun the following command for the base chains with the input, forward, and output hooks to implement a default DROP policy:# nft chain <table family> <table name> <chain name> { policy drop ; } Example: # nft chain inet filter input { policy drop ; } # nft chain inet filter forward { policy drop ; } # nft chain inet filter output { policy drop ; } Default Value: accept See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.2.9 Ensure nftables default deny firewall policy - inputInfoBase chain policy is the default verdict that will be applied to packets reaching the end of the chain.Rationale: There are two policies: accept (Default) and drop. If the policy is set to accept, the firewall will accept any packet that is not configured to be denied and the packet will continue traversing the network stack. It is easier to white list acceptable usage than to black list unacceptable usage. Note: Changing firewall settings while connected over the network can result in being locked out of the system. Impact: If configuring nftables over ssh, creating a base chain with a policy of drop will cause loss of connectivity. Ensure that a rule allowing ssh has been added to the base chain prior to setting the base chain's policy to drop SolutionRun the following command for the base chains with the input, forward, and output hooks to implement a default DROP policy:# nft chain <table family> <table name> <chain name> { policy drop ; } Example: # nft chain inet filter input { policy drop ; } # nft chain inet filter forward { policy drop ; } # nft chain inet filter output { policy drop ; } Default Value: accept See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.2.9 Ensure nftables default deny firewall policy - outputInfoBase chain policy is the default verdict that will be applied to packets reaching the end of the chain.Rationale: There are two policies: accept (Default) and drop. If the policy is set to accept, the firewall will accept any packet that is not configured to be denied and the packet will continue traversing the network stack. It is easier to white list acceptable usage than to black list unacceptable usage. Note: Changing firewall settings while connected over the network can result in being locked out of the system. Impact: If configuring nftables over ssh, creating a base chain with a policy of drop will cause loss of connectivity. Ensure that a rule allowing ssh has been added to the base chain prior to setting the base chain's policy to drop SolutionRun the following command for the base chains with the input, forward, and output hooks to implement a default DROP policy:# nft chain <table family> <table name> <chain name> { policy drop ; } Example: # nft chain inet filter input { policy drop ; } # nft chain inet filter forward { policy drop ; } # nft chain inet filter output { policy drop ; } Default Value: accept See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.3.1.1 Ensure iptables packages are installed - iptablesInfoiptables is a utility program that allows a system administrator to configure the tables provided by the Linux kernel firewall, implemented as different Netfilter modules, and the chains and rules it stores. Different kernel modules and programs are used for different protocols; iptables applies to IPv4, ip6tables to IPv6, arptables to ARP, and ebtables to Ethernet frames.Rationale: A method of configuring and maintaining firewall rules is necessary to configure a Host Based Firewall. SolutionRun the following command to install iptables and iptables-services# yum install iptables iptables-services See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.3.1.1 Ensure iptables packages are installed - iptables-servicesInfoiptables is a utility program that allows a system administrator to configure the tables provided by the Linux kernel firewall, implemented as different Netfilter modules, and the chains and rules it stores. Different kernel modules and programs are used for different protocols; iptables applies to IPv4, ip6tables to IPv6, arptables to ARP, and ebtables to Ethernet frames.Rationale: A method of configuring and maintaining firewall rules is necessary to configure a Host Based Firewall. SolutionRun the following command to install iptables and iptables-services# yum install iptables iptables-services See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.3.1.2 Ensure nftables is not installed with iptablesInfonftables is a subsystem of the Linux kernel providing filtering and classification of network packets/datagrams/frames and is the successor to iptables.Rationale: Running both iptables and nftables may lead to conflict. SolutionRun the following command to remove nftables:# yum remove nftables See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.3.1.3 Ensure firewalld is either not installed or masked with iptables - maskedInfofirewalld (Dynamic Firewall Manager) provides a dynamically managed firewall with support for network/firewall 'zones' to assign a level of trust to a network and its associated connections, interfaces or sources. It has support for IPv4, IPv6, Ethernet bridges and also for IPSet firewall settings. There is a separation of the runtime and permanent configuration options.Rationale: Running iptables.service andor ip6tables.service with firewalld.service may lead to conflict and unexpected results. SolutionRun the following command to remove firewalld# yum remove firewalld OR Run the following command to stop and mask firewalld # systemctl --now mask firewalld See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.3.1.3 Ensure firewalld is either not installed or masked with iptables - stoppedInfofirewalld (Dynamic Firewall Manager) provides a dynamically managed firewall with support for network/firewall 'zones' to assign a level of trust to a network and its associated connections, interfaces or sources. It has support for IPv4, IPv6, Ethernet bridges and also for IPSet firewall settings. There is a separation of the runtime and permanent configuration options.Rationale: Running iptables.service andor ip6tables.service with firewalld.service may lead to conflict and unexpected results. SolutionRun the following command to remove firewalld# yum remove firewalld OR Run the following command to stop and mask firewalld # systemctl --now mask firewalld See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.3.2.1 Ensure iptables loopback traffic is configured - Chain FORWARDInfoConfigure the loopback interface to accept traffic. Configure all other interfaces to deny traffic to the loopback network (127.0.0.0/8).Rationale: Loopback traffic is generated between processes on machine and is typically critical to operation of the system. The loopback interface is the only place that loopback network (127.0.0.0/8) traffic should be seen, all other interfaces should ignore traffic on this network as an anti-spoofing measure. Note: Changing firewall settings while connected over network can result in being locked out of the system. SolutionRun the following commands to implement the loopback rules:# iptables -A INPUT -i lo -j ACCEPT # iptables -A OUTPUT -o lo -j ACCEPT # iptables -A INPUT -s 127.0.0.0/8 -j DROP See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.3.2.1 Ensure iptables loopback traffic is configured - Chain INPUTInfoConfigure the loopback interface to accept traffic. Configure all other interfaces to deny traffic to the loopback network (127.0.0.0/8).Rationale: Loopback traffic is generated between processes on machine and is typically critical to operation of the system. The loopback interface is the only place that loopback network (127.0.0.0/8) traffic should be seen, all other interfaces should ignore traffic on this network as an anti-spoofing measure. Note: Changing firewall settings while connected over network can result in being locked out of the system. SolutionRun the following commands to implement the loopback rules:# iptables -A INPUT -i lo -j ACCEPT # iptables -A OUTPUT -o lo -j ACCEPT # iptables -A INPUT -s 127.0.0.0/8 -j DROP See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.3.2.1 Ensure iptables loopback traffic is configured - Chain OUTPUTInfoConfigure the loopback interface to accept traffic. Configure all other interfaces to deny traffic to the loopback network (127.0.0.0/8).Rationale: Loopback traffic is generated between processes on machine and is typically critical to operation of the system. The loopback interface is the only place that loopback network (127.0.0.0/8) traffic should be seen, all other interfaces should ignore traffic on this network as an anti-spoofing measure. Note: Changing firewall settings while connected over network can result in being locked out of the system. SolutionRun the following commands to implement the loopback rules:# iptables -A INPUT -i lo -j ACCEPT # iptables -A OUTPUT -o lo -j ACCEPT # iptables -A INPUT -s 127.0.0.0/8 -j DROP See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.3.2.2 Ensure iptables outbound and established connections are configured - inputInfoConfigure the firewall rules for new outbound, and established connections.Rationale: If rules are not in place for new outbound, and established connections all packets will be dropped by the default policy preventing network usage. Note: Changing firewall settings while connected over network can result in being locked out of the system. SolutionConfigure iptables in accordance with site policy. The following commands will implement a policy to allow all outbound connections and all established connections:# iptables -A OUTPUT -p tcp -m state --state NEW,ESTABLISHED -j ACCEPT # iptables -A OUTPUT -p udp -m state --state NEW,ESTABLISHED -j ACCEPT # iptables -A OUTPUT -p icmp -m state --state NEW,ESTABLISHED -j ACCEPT # iptables -A INPUT -p tcp -m state --state ESTABLISHED -j ACCEPT # iptables -A INPUT -p udp -m state --state ESTABLISHED -j ACCEPT # iptables -A INPUT -p icmp -m state --state ESTABLISHED -j ACCEPT See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.3.2.2 Ensure iptables outbound and established connections are configured - outputInfoConfigure the firewall rules for new outbound, and established connections.Rationale: If rules are not in place for new outbound, and established connections all packets will be dropped by the default policy preventing network usage. Note: Changing firewall settings while connected over network can result in being locked out of the system. SolutionConfigure iptables in accordance with site policy. The following commands will implement a policy to allow all outbound connections and all established connections:# iptables -A OUTPUT -p tcp -m state --state NEW,ESTABLISHED -j ACCEPT # iptables -A OUTPUT -p udp -m state --state NEW,ESTABLISHED -j ACCEPT # iptables -A OUTPUT -p icmp -m state --state NEW,ESTABLISHED -j ACCEPT # iptables -A INPUT -p tcp -m state --state ESTABLISHED -j ACCEPT # iptables -A INPUT -p udp -m state --state ESTABLISHED -j ACCEPT # iptables -A INPUT -p icmp -m state --state ESTABLISHED -j ACCEPT See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.3.2.3 Ensure iptables rules exist for all open portsInfoAny ports that have been opened on non-loopback addresses need firewall rules to govern traffic.Rationale: Without a firewall rule configured for open ports default firewall policy will drop all packets to these ports. Note: Changing firewall settings while connected over network can result in being locked out of the system. The remediation command opens up the port to traffic from all sources. Consult iptables documentation and set any restrictions in compliance with site policy. SolutionFor each port identified in the audit which does not have a firewall rule establish a proper rule for accepting inbound connections:# iptables -A INPUT -p <protocol> --dport <port> -m state --state NEW -j ACCEPT See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.3.2.4 Ensure iptables default deny firewall policyInfoA default deny all policy on connections ensures that any unconfigured network usage will be rejected.Rationale: With a default accept policy the firewall will accept any packet that is not configured to be denied. It is easier to white list acceptable usage than to black list unacceptable usage. Note: Changing firewall settings while connected over network can result in being locked out of the system. SolutionRun the following commands to implement a default DROP policy:# iptables -P INPUT DROP # iptables -P OUTPUT DROP # iptables -P FORWARD DROP See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.3.2.5 Ensure iptables rules are savedInfoThe iptables-services package includes the /etc/sysconfig/iptables file. The iptables rules in this file will be loaded by the iptables.service during boot, or when it is started or re-loaded.Rationale: If the iptables rules are not saved and a system re-boot occurs, the iptables rules will be lost. SolutionRun the following commands to create or update the /etc/sysconfig/iptables file:Run the following command to review the current running iptables configuration: # iptables -L Output should include: Chain INPUT (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere DROP all -- loopback/8 anywhere ACCEPT tcp -- anywhere anywhere state ESTABLISHED ACCEPT udp -- anywhere anywhere state ESTABLISHED ACCEPT icmp -- anywhere anywhere state ESTABLISHED ACCEPT tcp -- anywhere anywhere tcp dpt:ssh state NEW Chain FORWARD (policy DROP) target prot opt source destination Chain OUTPUT (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT tcp -- anywhere anywhere state NEW,ESTABLISHED ACCEPT udp -- anywhere anywhere state NEW,ESTABLISHED ACCEPT icmp -- anywhere anywhere state NEW,ESTABLISHED Run the following command to save the verified running configuration to the file /etc/sysconfig/iptables: # service iptables save iptables: Saving firewall rules to /etc/sysconfig/iptables:[ OK ] See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.3.2.6 Ensure iptables is enabled and running - enabledInfoiptables.service is a utility for configuring and maintaining iptables.Rationale: iptables.service will load the iptables rules saved in the file /etc/sysconfig/iptables at boot, otherwise the iptables rules will be cleared during a re-boot of the system. SolutionRun the following command to enable and start iptables:# systemctl --now enable iptables See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.3.2.6 Ensure iptables is enabled and running - runningInfoiptables.service is a utility for configuring and maintaining iptables.Rationale: iptables.service will load the iptables rules saved in the file /etc/sysconfig/iptables at boot, otherwise the iptables rules will be cleared during a re-boot of the system. SolutionRun the following command to enable and start iptables:# systemctl --now enable iptables See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.3.3.1 Ensure ip6tables loopback traffic is configured - Chain FORWARDInfoConfigure the loopback interface to accept traffic. Configure all other interfaces to deny traffic to the loopback network (::1).Rationale: Loopback traffic is generated between processes on machine and is typically critical to operation of the system. The loopback interface is the only place that loopback network (::1) traffic should be seen, all other interfaces should ignore traffic on this network as an anti-spoofing measure. Note: Changing firewall settings while connected over network can result in being locked out of the system. SolutionRun the following commands to implement the loopback rules:# ip6tables -A INPUT -i lo -j ACCEPT # ip6tables -A OUTPUT -o lo -j ACCEPT # ip6tables -A INPUT -s ::1 -j DROP See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.3.3.1 Ensure ip6tables loopback traffic is configured - Chain INPUTInfoConfigure the loopback interface to accept traffic. Configure all other interfaces to deny traffic to the loopback network (::1).Rationale: Loopback traffic is generated between processes on machine and is typically critical to operation of the system. The loopback interface is the only place that loopback network (::1) traffic should be seen, all other interfaces should ignore traffic on this network as an anti-spoofing measure. Note: Changing firewall settings while connected over network can result in being locked out of the system. SolutionRun the following commands to implement the loopback rules:# ip6tables -A INPUT -i lo -j ACCEPT # ip6tables -A OUTPUT -o lo -j ACCEPT # ip6tables -A INPUT -s ::1 -j DROP See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.3.3.1 Ensure ip6tables loopback traffic is configured - Chain OUTPUTInfoConfigure the loopback interface to accept traffic. Configure all other interfaces to deny traffic to the loopback network (::1).Rationale: Loopback traffic is generated between processes on machine and is typically critical to operation of the system. The loopback interface is the only place that loopback network (::1) traffic should be seen, all other interfaces should ignore traffic on this network as an anti-spoofing measure. Note: Changing firewall settings while connected over network can result in being locked out of the system. SolutionRun the following commands to implement the loopback rules:# ip6tables -A INPUT -i lo -j ACCEPT # ip6tables -A OUTPUT -o lo -j ACCEPT # ip6tables -A INPUT -s ::1 -j DROP See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.3.3.2 Ensure ip6tables outbound and established connections are configured - INPUTInfoConfigure the firewall rules for new outbound, and established IPv6 connections.Rationale: If rules are not in place for new outbound, and established connections all packets will be dropped by the default policy preventing network usage. Note: Changing firewall settings while connected over network can result in being locked out of the system. SolutionConfigure iptables in accordance with site policy. The following commands will implement a policy to allow all outbound connections and all established connections:# ip6tables -A OUTPUT -p tcp -m state --state NEW,ESTABLISHED -j ACCEPT # ip6tables -A OUTPUT -p udp -m state --state NEW,ESTABLISHED -j ACCEPT # ip6tables -A OUTPUT -p icmp -m state --state NEW,ESTABLISHED -j ACCEPT # ip6tables -A INPUT -p tcp -m state --state ESTABLISHED -j ACCEPT # ip6tables -A INPUT -p udp -m state --state ESTABLISHED -j ACCEPT # ip6tables -A INPUT -p icmp -m state --state ESTABLISHED -j ACCEPT See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.3.3.2 Ensure ip6tables outbound and established connections are configured - OUTPUTInfoConfigure the firewall rules for new outbound, and established IPv6 connections.Rationale: If rules are not in place for new outbound, and established connections all packets will be dropped by the default policy preventing network usage. Note: Changing firewall settings while connected over network can result in being locked out of the system. SolutionConfigure iptables in accordance with site policy. The following commands will implement a policy to allow all outbound connections and all established connections:# ip6tables -A OUTPUT -p tcp -m state --state NEW,ESTABLISHED -j ACCEPT # ip6tables -A OUTPUT -p udp -m state --state NEW,ESTABLISHED -j ACCEPT # ip6tables -A OUTPUT -p icmp -m state --state NEW,ESTABLISHED -j ACCEPT # ip6tables -A INPUT -p tcp -m state --state ESTABLISHED -j ACCEPT # ip6tables -A INPUT -p udp -m state --state ESTABLISHED -j ACCEPT # ip6tables -A INPUT -p icmp -m state --state ESTABLISHED -j ACCEPT See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.3.3.3 Ensure ip6tables firewall rules exist for all open portsInfoAny ports that have been opened on non-loopback addresses need firewall rules to govern traffic.Rationale: Without a firewall rule configured for open ports default firewall policy will drop all packets to these ports. Note: Changing firewall settings while connected over network can result in being locked out of the system. The remediation command opens up the port to traffic from all sources. Consult iptables documentation and set any restrictions in compliance with site policy. SolutionFor each port identified in the audit which does not have a firewall rule establish a proper rule for accepting inbound connections:# ip6tables -A INPUT -p <protocol> --dport <port> -m state --state NEW -j ACCEPT See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.3.3.4 Ensure ip6tables default deny firewall policyInfoA default deny all policy on connections ensures that any unconfigured network usage will be rejected.Rationale: With a default accept policy the firewall will accept any packet that is not configured to be denied. It is easier to white list acceptable usage than to black list unacceptable usage. Note: Changing firewall settings while connected over network can result in being locked out of the system. SolutionRun the following commands to implement a default DROP policy:# ip6tables -P INPUT DROP # ip6tables -P OUTPUT DROP # ip6tables -P FORWARD DROP See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.3.3.5 Ensure ip6tables rules are savedInfoThe iptables-services package includes the /etc/sysconfig/ip6tables file. The ip6tables rules in this file will be loaded by the ip6tables.service during boot, or when it is started or re-loaded.Rationale: If the ip6tables rules are not saved and a system re-boot occurs, the ip6tables rules will be lost. SolutionRun the following commands to create or update the /etc/sysconfig/ip6tables file:Run the following command to review the current running iptables configuration: # ip6tables -L Output should include: Chain INPUT (policy DROP) target prot opt source destination ACCEPT all anywhere anywhere DROP all localhost anywhere ACCEPT tcp anywhere anywhere state ESTABLISHED ACCEPT udp anywhere anywhere state ESTABLISHED ACCEPT icmp anywhere anywhere state ESTABLISHED ACCEPT tcp anywhere anywhere tcp dpt:ssh state NEW Chain FORWARD (policy DROP) target prot opt source destination Chain OUTPUT (policy DROP) target prot opt source destination ACCEPT all anywhere anywhere ACCEPT tcp anywhere anywhere state NEW,ESTABLISHED ACCEPT udp anywhere anywhere state NEW,ESTABLISHED ACCEPT icmp anywhere anywhere state NEW,ESTABLISHED Run the following command to save the verified running configuration to the file /etc/sysconfig/ip6tables: # service ip6tables save ip6tables: Saving firewall rules to /etc/sysconfig/ip6table[ OK ] See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.3.3.6 Ensure ip6tables is enabled and runningInfoip6tables.service is a utility for configuring and maintaining ip6tables.Rationale: ip6tables.service will load the iptables rules saved in the file /etc/sysconfig/ip6tables at boot, otherwise the ip6tables rules will be cleared during a re-boot of the system. SolutionRun the following command to enable and start ip6tables:# systemctl --now start ip6tables See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa3.5.3.3.6 Ensure ip6tables is enabled and running - enabledInfoip6tables.service is a utility for configuring and maintaining ip6tables.Rationale: ip6tables.service will load the iptables rules saved in the file /etc/sysconfig/ip6tables at boot, otherwise the ip6tables rules will be cleared during a re-boot of the system. SolutionRun the following command to enable and start ip6tables:# systemctl --now start ip6tables See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa4.2.1.1 Ensure rsyslog is installedInfoThe rsyslog software is recommended in environments where journald does not meet operation requirements.Rationale: The security enhancements of rsyslog such as connection-oriented (i.e. TCP) transmission of logs, the option to log to database formats, and the encryption of log data en route to a central logging server) justify installing and configuring the package. SolutionRun the following command to install rsyslog:# apt install rsyslog See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe local RPM is newer than rsyslog-0.0.0-0 (rsyslog-8.24.0-57.el7_9.3)
lab-preventaThe local RPM is newer than rsyslog-0.0.0-0 (rsyslog-8.24.0-57.el7_9.3)
4.2.1.2 Ensure rsyslog service is enabled and runningInfoOnce the rsyslog package is installed, ensure that the service is enabled.Rationale: If the rsyslog service is not enabled to start on boot, the system will not capture logging events. SolutionRun the following command to enable rsyslog:# systemctl --now enable rsyslog See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/bin/systemctl is-enabled rsyslog | /usr/bin/awk '{print} END {if(NR==0) print "disabled" }'' returned :
enabled lab-preventaThe command '/bin/systemctl is-enabled rsyslog | /usr/bin/awk '{print} END {if(NR==0) print "disabled" }'' returned :
enabled 5.1.1 Ensure cron daemon is enabled and running - enabledInfoThe cron daemon is used to execute batch jobs on the system.Rationale: While there may not be user jobs that need to be run on the system, the system does have maintenance jobs that may include security monitoring that have to run. If another method for scheduling tasks is not being used, cron is used to execute them, and needs to be enabled and running. SolutionRun the following command to enable and start cron:# systemctl --now enable crond OR Run the following command to remove cron: # yum remove cronie See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa5.1.1 Ensure cron daemon is enabled and running - runningInfoThe cron daemon is used to execute batch jobs on the system.Rationale: While there may not be user jobs that need to be run on the system, the system does have maintenance jobs that may include security monitoring that have to run. If another method for scheduling tasks is not being used, cron is used to execute them, and needs to be enabled and running. SolutionRun the following command to enable and start cron:# systemctl --now enable crond OR Run the following command to remove cron: # yum remove cronie See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa5.1.2 Ensure permissions on /etc/crontab are configuredInfoThe /etc/crontab file is used by cron to control its own jobs. The commands in this item make sure that root is the user and group owner of the file and that only the owner can access the file.Rationale: This file contains information on what system jobs are run by cron. Write access to these files could provide unprivileged users with the ability to elevate their privileges. Read access to these files could provide users with the ability to gain insight on system jobs that run on the system and could provide them a way to gain unauthorized privileged access. SolutionRun the following commands to set ownership and permissions on /etc/crontab:# chown root:root /etc/crontab # chmod u-x,og-rwx /etc/crontab OR Run the following command to remove cron: # yum remove cronie See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa5.1.3 Ensure permissions on /etc/cron.hourly are configuredInfoThis directory contains system cron jobs that need to run on an hourly basis. The files in this directory cannot be manipulated by the crontab command, but are instead edited by system administrators using a text editor. The commands below restrict read/write and search access to user and group root, preventing regular users from accessing this directory.Rationale: Granting write access to this directory for non-privileged users could provide them the means for gaining unauthorized elevated privileges. Granting read access to this directory could give an unprivileged user insight in how to gain elevated privileges or circumvent auditing controls. SolutionRun the following commands to set ownership and permissions on the /etc/cron.hourly/ directory:# chown root:root /etc/cron.hourly/ # chmod og-rwx /etc/cron.hourly/ OR Run the following command to remove cron # yum remove cronie See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa5.1.4 Ensure permissions on /etc/cron.daily are configuredInfoThe /etc/cron.daily directory contains system cron jobs that need to run on a daily basis. The files in this directory cannot be manipulated by the crontab command, but are instead edited by system administrators using a text editor. The commands below restrict read/write and search access to user and group root, preventing regular users from accessing this directory.Rationale: Granting write access to this directory for non-privileged users could provide them the means for gaining unauthorized elevated privileges. Granting read access to this directory could give an unprivileged user insight in how to gain elevated privileges or circumvent auditing controls. SolutionRun the following commands to set ownership and permissions on /etc/cron.daily directory:# chown root:root /etc/cron.daily # chmod og-rwx /etc/cron.daily OR Run the following command to remove cron: # yum remove cronie See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa5.1.5 Ensure permissions on /etc/cron.weekly are configuredInfoThe /etc/cron.weekly directory contains system cron jobs that need to run on a weekly basis. The files in this directory cannot be manipulated by the crontab command, but are instead edited by system administrators using a text editor. The commands below restrict read/write and search access to user and group root, preventing regular users from accessing this directory.Rationale: Granting write access to this directory for non-privileged users could provide them the means for gaining unauthorized elevated privileges. Granting read access to this directory could give an unprivileged user insight in how to gain elevated privileges or circumvent auditing controls. SolutionRun the following commands to set ownership and permissions on /etc/cron.weekly/ directory:# chown root:root /etc/cron.weekly/ # chmod og-rwx /etc/cron.weekly/ OR Run the following command to remove cron: # yum remove cronie See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa5.1.6 Ensure permissions on /etc/cron.monthly are configuredInfoThe /etc/cron.monthly directory contains system cron jobs that need to run on a monthly basis. The files in this directory cannot be manipulated by the crontab command, but are instead edited by system administrators using a text editor. The commands below restrict read/write and search access to user and group root, preventing regular users from accessing this directory.Rationale: Granting write access to this directory for non-privileged users could provide them the means for gaining unauthorized elevated privileges. Granting read access to this directory could give an unprivileged user insight in how to gain elevated privileges or circumvent auditing controls. SolutionRun the following commands to set ownership and permissions on /etc/cron.monthly directory:# chown root:root /etc/cron.monthly # chmod og-rwx /etc/cron.monthly OR Run the following command to remove cron: # yum remove cronie See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa5.1.7 Ensure permissions on /etc/cron.d are configuredInfoThe /etc/cron.d/ directory contains system cron jobs that need to run in a similar manner to the hourly, daily weekly and monthly jobs from /etc/crontab , but require more granular control as to when they run. The files in this directory cannot be manipulated by the crontab command, but are instead edited by system administrators using a text editor. The commands below restrict read/write and search access to user and group root, preventing regular users from accessing this directory.Rationale: Granting write access to this directory for non-privileged users could provide them the means for gaining unauthorized elevated privileges. Granting read access to this directory could give an unprivileged user insight in how to gain elevated privileges or circumvent auditing controls. SolutionRun the following commands to set ownership and permissions on /etc/cron.d directory:# chown root:root /etc/cron.d # chmod og-rwx /etc/cron.d OR Run the following command to remove cron: # yum remove cronie See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa5.1.8 Ensure cron is restricted to authorized users - /etc/cron.allowInfoIf cron is installed in the system, configure /etc/cron.allow to allow specific users to use these services. If /etc/cron.allow does not exist, then /etc/cron.deny is checked. Any user not specifically defined in those files is allowed to use cron. By removing the file, only users in /etc/cron.allow are allowed to use cron.Note: Even though a given user is not listed in cron.allow, cron jobs can still be run as that user. The cron.allow file only controls administrative access to the crontab command for scheduling and modifying cron jobs. Rationale: On many systems, only the system administrator is authorized to schedule cron jobs. Using the cron.allow file to control who can run cron jobs enforces this policy. It is easier to manage an allow list than a deny list. In a deny list, you could potentially add a user ID to the system and forget to add it to the deny files. SolutionRun the following command to remove /etc/cron.deny:# rm /etc/cron.deny Run the following command to create /etc/cron.allow # touch /etc/cron.allow Run the following commands to set the owner and permissions on /etc/cron.allow: # chown root:root /etc/cron.allow # chmod u-x,og-rwx /etc/cron.allow OR Run the following command to remove cron # yum remove cronie See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa5.1.8 Ensure cron is restricted to authorized users - /etc/cron.denyInfoIf cron is installed in the system, configure /etc/cron.allow to allow specific users to use these services. If /etc/cron.allow does not exist, then /etc/cron.deny is checked. Any user not specifically defined in those files is allowed to use cron. By removing the file, only users in /etc/cron.allow are allowed to use cron.Note: Even though a given user is not listed in cron.allow, cron jobs can still be run as that user. The cron.allow file only controls administrative access to the crontab command for scheduling and modifying cron jobs. Rationale: On many systems, only the system administrator is authorized to schedule cron jobs. Using the cron.allow file to control who can run cron jobs enforces this policy. It is easier to manage an allow list than a deny list. In a deny list, you could potentially add a user ID to the system and forget to add it to the deny files. SolutionRun the following command to remove /etc/cron.deny:# rm /etc/cron.deny Run the following command to create /etc/cron.allow # touch /etc/cron.allow Run the following commands to set the owner and permissions on /etc/cron.allow: # chown root:root /etc/cron.allow # chmod u-x,og-rwx /etc/cron.allow OR Run the following command to remove cron # yum remove cronie See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa5.1.9 Ensure at is restricted to authorized users - /etc/at.allowInfoIf at is installed in the system, configure /etc/at.allow to allow specific users to use these services. If /etc/at.allow does not exist, then /etc/at.deny is checked. Any user not specifically defined in those files is allowed to use at. By removing the file, only users in /etc/at.allow are allowed to use at.Note: Even though a given user is not listed in at.allow, at jobs can still be run as that user. The at.allow file only controls administrative access to the at command for scheduling and modifying at jobs. Rationale: On many systems, only the system administrator is authorized to schedule at jobs. Using the at.allow file to control who can run at jobs enforces this policy. It is easier to manage an allow list than a deny list. In a deny list, you could potentially add a user ID to the system and forget to add it to the deny files. SolutionRun the following command to remove /etc/at.deny:# rm /etc/at.deny Run the following command to create /etc/at.allow # touch /etc/at.allow Run the following commands to set the owner and permissions on /etc/at.allow: # chown root:root /etc/at.allow # chmod u-x,og-rwx /etc/at.allow OR Run the following command to remove at: # yum remove at See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa5.1.9 Ensure at is restricted to authorized users - /etc/at.denyInfoIf at is installed in the system, configure /etc/at.allow to allow specific users to use these services. If /etc/at.allow does not exist, then /etc/at.deny is checked. Any user not specifically defined in those files is allowed to use at. By removing the file, only users in /etc/at.allow are allowed to use at.Note: Even though a given user is not listed in at.allow, at jobs can still be run as that user. The at.allow file only controls administrative access to the at command for scheduling and modifying at jobs. Rationale: On many systems, only the system administrator is authorized to schedule at jobs. Using the at.allow file to control who can run at jobs enforces this policy. It is easier to manage an allow list than a deny list. In a deny list, you could potentially add a user ID to the system and forget to add it to the deny files. SolutionRun the following command to remove /etc/at.deny:# rm /etc/at.deny Run the following command to create /etc/at.allow # touch /etc/at.allow Run the following commands to set the owner and permissions on /etc/at.allow: # chown root:root /etc/at.allow # chmod u-x,og-rwx /etc/at.allow OR Run the following command to remove at: # yum remove at See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa5.2.1 Ensure sudo is installedInfosudo allows a permitted user to execute a command as the superuser or another user, as specified by the security policy. The invoking user's real (not effective) user ID is used to determine the user name with which to query the security policy.Rationale: sudo supports a plugin architecture for security policies and input/output logging. Third parties can develop and distribute their own policy and I/O logging plugins to work seamlessly with the sudo front end. The default security policy is sudoers, which is configured via the file /etc/sudoers. The security policy determines what privileges, if any, a user has to run sudo. The policy may require that users authenticate themselves with a password or another authentication mechanism. If authentication is required, sudo will exit if the user's password is not entered within a configurable time limit. This limit is policy-specific. SolutionRun the following command to install sudo.# yum install sudo See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe local RPM is newer than sudo-0.0.0-0 (sudo-1.8.23-10.el7_9.3)
lab-preventaThe local RPM is newer than sudo-0.0.0-0 (sudo-1.8.23-10.el7_9.3)
5.3.1 Ensure permissions on /etc/ssh/sshd_config are configuredInfoThe /etc/ssh/sshd_config file contains configuration specifications for sshd. The command below sets the owner and group of the file to root.Rationale: The /etc/ssh/sshd_config file needs to be protected from unauthorized changes by non-privileged users. SolutionRun the following commands to set ownership and permissions on /etc/ssh/sshd_config:# chown root:root /etc/ssh/sshd_config # chmod og-rwx /etc/ssh/sshd_config Default Value: Access: (0600/-rw-------) Uid: ( 0/ root) Gid: ( 0/ root) See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe file /etc/ssh/sshd_config with fmode owner: root group: root mode: 0600 uid: 0 gid: 0 uneven permissions : FALSE is compliant with the policy value
/etc/ssh/sshd_config lab-preventaThe file /etc/ssh/sshd_config with fmode owner: root group: root mode: 0600 uid: 0 gid: 0 uneven permissions : FALSE is compliant with the policy value
/etc/ssh/sshd_config 5.3.11 Ensure SSH PermitEmptyPasswords is disabledInfoThe PermitEmptyPasswords parameter specifies if the SSH server allows login to accounts with empty password strings.Rationale: Disallowing remote shell access to accounts that have an empty password reduces the probability of unauthorized access to the system SolutionEdit the /etc/ssh/sshd_config file to set the parameter as follows:PermitEmptyPasswords no Default Value: PermitEmptyPasswords no See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sshd -T | /usr/bin/grep -P -i '^[\s]*PermitEmptyPasswords[\s]'' returned :
permitemptypasswords no lab-preventaThe command '/usr/sbin/sshd -T | /usr/bin/grep -P -i '^[\s]*PermitEmptyPasswords[\s]'' returned :
permitemptypasswords no 5.3.12 Ensure SSH PermitUserEnvironment is disabledInfoThe PermitUserEnvironment option allows users to present environment options to the ssh daemon.Rationale: Permitting users the ability to set environment variables through the SSH daemon could potentially allow users to bypass security controls (e.g. setting an execution path that has ssh executing a Trojan's programs) SolutionEdit the /etc/ssh/sshd_config file to set the parameter as follows:PermitUserEnvironment no Default Value: PermitUserEnvironment no See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sshd -T | /usr/bin/grep -P -i '^[\s]*PermitUserEnvironment[\s]'' returned :
permituserenvironment no lab-preventaThe command '/usr/sbin/sshd -T | /usr/bin/grep -P -i '^[\s]*PermitUserEnvironment[\s]'' returned :
permituserenvironment no 5.3.13 Ensure only strong Ciphers are used - approved ciphersInfoThis variable limits the ciphers that SSH can use during communication.Note: Some organizations may have stricter requirements for approved ciphers. Ensure that ciphers used are in compliance with site policy. Rationale: Weak ciphers that are used for authentication to the cryptographic module cannot be relied upon to provide confidentiality or integrity, and system data may be compromised. The DES, Triple DES, and Blowfish ciphers, as used in SSH, have a birthday bound of approximately four billion blocks, which makes it easier for remote attackers to obtain cleartext data via a birthday attack against a long-duration encrypted session, aka a 'Sweet32' attack The RC4 algorithm, as used in the TLS protocol and SSL protocol, does not properly combine state data with key data during the initialization phase, which makes it easier for remote attackers to conduct plaintext-recovery attacks against the initial bytes of a stream by sniffing network traffic that occasionally relies on keys affected by the Invariance Weakness, and then using a brute-force approach involving LSB values, aka the 'Bar Mitzvah' issue The passwords used during an SSH session encrypted with RC4 can be recovered by an attacker who is able to capture and replay the session Error handling in the SSH protocol; Client and Server, when using a block cipher algorithm in Cipher Block Chaining (CBC) mode, makes it easier for remote attackers to recover certain plaintext data from an arbitrary block of ciphertext in an SSH session via unknown vectors SolutionEdit the /etc/ssh/sshd_config file add/modify the Ciphers line to contain a comma separated list of the site approved ciphers Example:Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr Default Value: Ciphers chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,cast128-cbc,3des-cbc See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sshd -T | /usr/bin/grep -P -i '^[\s]*[Cc]iphers[\s]+'' returned :
ciphers chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,cast128-cbc,3des-cbc lab-preventaThe command '/usr/sbin/sshd -T | /usr/bin/grep -P -i '^[\s]*[Cc]iphers[\s]+'' returned :
ciphers chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,cast128-cbc,3des-cbc 5.3.13 Ensure only strong Ciphers are used - weak ciphersInfoThis variable limits the ciphers that SSH can use during communication.Note: Some organizations may have stricter requirements for approved ciphers. Ensure that ciphers used are in compliance with site policy. Rationale: Weak ciphers that are used for authentication to the cryptographic module cannot be relied upon to provide confidentiality or integrity, and system data may be compromised. The DES, Triple DES, and Blowfish ciphers, as used in SSH, have a birthday bound of approximately four billion blocks, which makes it easier for remote attackers to obtain cleartext data via a birthday attack against a long-duration encrypted session, aka a 'Sweet32' attack The RC4 algorithm, as used in the TLS protocol and SSL protocol, does not properly combine state data with key data during the initialization phase, which makes it easier for remote attackers to conduct plaintext-recovery attacks against the initial bytes of a stream by sniffing network traffic that occasionally relies on keys affected by the Invariance Weakness, and then using a brute-force approach involving LSB values, aka the 'Bar Mitzvah' issue The passwords used during an SSH session encrypted with RC4 can be recovered by an attacker who is able to capture and replay the session Error handling in the SSH protocol; Client and Server, when using a block cipher algorithm in Cipher Block Chaining (CBC) mode, makes it easier for remote attackers to recover certain plaintext data from an arbitrary block of ciphertext in an SSH session via unknown vectors SolutionEdit the /etc/ssh/sshd_config file add/modify the Ciphers line to contain a comma separated list of the site approved ciphers Example:Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr Default Value: Ciphers chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,cast128-cbc,3des-cbc See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe file "/etc/ssh/sshd_config" does not contain "^[\s]*[Cc]iphers[\s]+"
lab-preventaThe file "/etc/ssh/sshd_config" does not contain "^[\s]*[Cc]iphers[\s]+"
5.3.14 Ensure only strong MAC algorithms are used - weak MACsInfoThis variable Specifies the available MAC (message authentication code) algorithms. The MAC algorithm is used in protocol version 2 for data integrity protection. Multiple algorithms must be comma-separated.Note: Some organizations may have stricter requirements for approved MACs. Ensure that MACs used are in compliance with site policy. Rationale: MD5 and 96-bit MAC algorithms are considered weak and have been shown to increase exploitability in SSH downgrade attacks. Weak algorithms continue to have a great deal of attention as a weak spot that can be exploited with expanded computing power. An attacker that breaks the algorithm could take advantage of a MiTM position to decrypt the SSH tunnel and capture credentials and information SolutionEdit the /etc/ssh/sshd_config file and add/modify the MACs line to contain a comma separated list of the site approved MACs Example:MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-256 Default Value: MACs umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-sha1-etm@openssh.com See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe file "/etc/ssh/sshd_config" does not contain "^[\s]*[Mm][Aa][Cc][Ss][\s]+"
lab-preventaThe file "/etc/ssh/sshd_config" does not contain "^[\s]*[Mm][Aa][Cc][Ss][\s]+"
5.3.15 Ensure only strong Key Exchange algorithms are used - approved algorithmsInfoKey exchange is any method in cryptography by which cryptographic keys are exchanged between two parties, allowing use of a cryptographic algorithm. If the sender and receiver wish to exchange encrypted messages, each must be equipped to encrypt messages to be sent and decrypt messages receivedNote: Some organizations may have stricter requirements for approved Key Exchange algorithms. Ensure that Key Exchange algorithms used are in compliance with site policy. Rationale: Key exchange methods that are considered weak should be removed. A key exchange method may be weak because too few bits are used or the hashing algorithm is considered too weak. Using weak algorithms could expose connections to man-in-the-middle attacks SolutionEdit the /etc/ssh/sshd_config file add/modify the KexAlgorithms line to contain a comma separated list of the site approved key exchange algorithms Example:KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256 Default Value: kexalgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sshd -T | /usr/bin/grep -P -i '^[\s]*[Kk]ex[Aa]lgorithms[\s]+'' returned :
kexalgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 lab-preventaThe command '/usr/sbin/sshd -T | /usr/bin/grep -P -i '^[\s]*[Kk]ex[Aa]lgorithms[\s]+'' returned :
kexalgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 5.3.15 Ensure only strong Key Exchange algorithms are used - weak algorithmsInfoKey exchange is any method in cryptography by which cryptographic keys are exchanged between two parties, allowing use of a cryptographic algorithm. If the sender and receiver wish to exchange encrypted messages, each must be equipped to encrypt messages to be sent and decrypt messages receivedNote: Some organizations may have stricter requirements for approved Key Exchange algorithms. Ensure that Key Exchange algorithms used are in compliance with site policy. Rationale: Key exchange methods that are considered weak should be removed. A key exchange method may be weak because too few bits are used or the hashing algorithm is considered too weak. Using weak algorithms could expose connections to man-in-the-middle attacks SolutionEdit the /etc/ssh/sshd_config file add/modify the KexAlgorithms line to contain a comma separated list of the site approved key exchange algorithms Example:KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256 Default Value: kexalgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe file "/etc/ssh/sshd_config" does not contain "^[\s]*[Kk]ex[Aa]lgorithms[\s]+"
lab-preventaThe file "/etc/ssh/sshd_config" does not contain "^[\s]*[Kk]ex[Aa]lgorithms[\s]+"
5.3.19 Ensure SSH PAM is enabledInfoUsePAM Enables the Pluggable Authentication Module interface. If set to 'yes' this will enable PAM authentication using ChallengeResponseAuthentication and PasswordAuthentication in addition to PAM account and session module processing for all authentication typesRationale: When usePAM is set to yes, PAM runs through account and session types properly. This is important if you want to restrict access to services based off of IP, time or other factors of the account. Additionally, you can make sure users inherit certain environment variables on login or disallow access to the server Impact: If UsePAM is enabled, you will not be able to run sshd(5) as a non-root user. SolutionEdit the /etc/ssh/sshd_config file to set the parameter as follows:UsePAM yes Default Value: usePAM yes See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sshd -T | /usr/bin/grep -P -i '^[\s]*[Uu]se[Pp][Aa][Mm][\s]'' returned :
usepam yes lab-preventaThe command '/usr/sbin/sshd -T | /usr/bin/grep -P -i '^[\s]*[Uu]se[Pp][Aa][Mm][\s]'' returned :
usepam yes 5.3.2 Ensure permissions on SSH private host key files are configuredInfoAn SSH private key is one of two files used in SSH public key authentication. In this authentication method, The possession of the private key is proof of identity. Only a private key that corresponds to a public key will be able to authenticate successfully. The private keys need to be stored and handled carefully, and no copies of the private key should be distributed.Rationale: If an unauthorized user obtains the private SSH host key file, the host could be impersonated SolutionRun the following commands to set permissions, ownership, and group on the private SSH host key files:# find /etc/ssh -xdev -type f -name 'ssh_host_*_key' -exec chown root:root {} ; # find /etc/ssh -xdev -type f -name 'ssh_host_*_key' -exec chmod u-x,go-rwx {} ; Default Value: Access: (0600/-rw-------) Uid: ( 0/ root) Gid: ( 0/ root) See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/find /etc/ssh -xdev -type f -name 'ssh_host_*_key' -exec stat -c '%a %n %U %G' {} \; | /usr/bin/awk -F' ' 'BEGIN { f=0; print "Octal, File, User, Group"; } { printf "%s, %s, %s, %s",$1,$2,$3,$4; if($4 ~ "root"){ if ($3 ~ "root" && $1 ~ /[1-6]00/){ printf " - pass";} else { ++f; printf " - fail"; } } else if($4 ~ "ssh_keys"){ if ($3 ~ "root" && $1 ~ /[1-6][0-4]0/){ printf " - pass";} else { ++f; printf " - fail"; } } printf "\n"; } END { if(f != 0){ print "Failures found"; } else { print "All files pass"; } }'' returned :
Octal, File, User, Group 640, /etc/ssh/ssh_host_rsa_key, root, ssh_keys - pass 640, /etc/ssh/ssh_host_ecdsa_key, root, ssh_keys - pass 640, /etc/ssh/ssh_host_ed25519_key, root, ssh_keys - pass All files pass lab-preventaThe command '/usr/bin/find /etc/ssh -xdev -type f -name 'ssh_host_*_key' -exec stat -c '%a %n %U %G' {} \; | /usr/bin/awk -F' ' 'BEGIN { f=0; print "Octal, File, User, Group"; } { printf "%s, %s, %s, %s",$1,$2,$3,$4; if($4 ~ "root"){ if ($3 ~ "root" && $1 ~ /[1-6]00/){ printf " - pass";} else { ++f; printf " - fail"; } } else if($4 ~ "ssh_keys"){ if ($3 ~ "root" && $1 ~ /[1-6][0-4]0/){ printf " - pass";} else { ++f; printf " - fail"; } } printf "\n"; } END { if(f != 0){ print "Failures found"; } else { print "All files pass"; } }'' returned :
Octal, File, User, Group 640, /etc/ssh/ssh_host_rsa_key, root, ssh_keys - pass 640, /etc/ssh/ssh_host_ecdsa_key, root, ssh_keys - pass 640, /etc/ssh/ssh_host_ed25519_key, root, ssh_keys - pass All files pass 5.3.22 Ensure SSH MaxSessions is limitedInfoThe MaxSessions parameter Specifies the maximum number of open sessions permitted per network connection.Rationale: To protect a system from denial of service due to a large number of concurrent sessions, use the rate limiting function of MaxSessions to protect availability of sshd logins and prevent overwhelming the daemon. SolutionEdit the /etc/ssh/sshd_config file to set the parameter as follows:MaxSessions 10 Default Value: MaxSessions 10 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sshd -T | /usr/bin/grep -P -i '^[\s]*[Mm]ax[Ss]essions[\s]'' returned :
maxsessions 10 lab-preventaThe command '/usr/sbin/sshd -T | /usr/bin/grep -P -i '^[\s]*[Mm]ax[Ss]essions[\s]'' returned :
maxsessions 10 5.3.3 Ensure permissions on SSH public host key files are configuredInfoAn SSH public key is one of two files used in SSH public key authentication. In this authentication method, a public key is a key that can be used for verifying digital signatures generated using a corresponding private key. Only a public key that corresponds to a private key will be able to authenticate successfully.Rationale: If a public host key file is modified by an unauthorized user, the SSH service may be compromised. SolutionRun the following commands to set permissions and ownership on the SSH host public key files# find /etc/ssh -xdev -type f -name 'ssh_host_*_key.pub' -exec chmod u-x,go-wx {} ; # find /etc/ssh -xdev -type f -name 'ssh_host_*_key.pub' -exec chown root:root {} ; Default Value: Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe file /etc/ssh/ssh_host_ecdsa_key.pub with fmode owner: root group: root mode: 0644 uid: 0 gid: 0 uneven permissions : FALSE is compliant with the policy value
The file /etc/ssh/ssh_host_ed25519_key.pub with fmode owner: root group: root mode: 0644 uid: 0 gid: 0 uneven permissions : FALSE is compliant with the policy value The file /etc/ssh/ssh_host_rsa_key.pub with fmode owner: root group: root mode: 0644 uid: 0 gid: 0 uneven permissions : FALSE is compliant with the policy value /etc/ssh/ssh_host_ecdsa_key.pub, /etc/ssh/ssh_host_ed25519_key.pub, /etc/ssh/ssh_host_rsa_key.pub lab-preventaThe file /etc/ssh/ssh_host_ecdsa_key.pub with fmode owner: root group: root mode: 0644 uid: 0 gid: 0 uneven permissions : FALSE is compliant with the policy value
The file /etc/ssh/ssh_host_ed25519_key.pub with fmode owner: root group: root mode: 0644 uid: 0 gid: 0 uneven permissions : FALSE is compliant with the policy value The file /etc/ssh/ssh_host_rsa_key.pub with fmode owner: root group: root mode: 0644 uid: 0 gid: 0 uneven permissions : FALSE is compliant with the policy value /etc/ssh/ssh_host_ecdsa_key.pub, /etc/ssh/ssh_host_ed25519_key.pub, /etc/ssh/ssh_host_rsa_key.pub 5.3.5 Ensure SSH LogLevel is appropriateInfoINFO level is the basic level that only records login activity of SSH users. In many situations, such as Incident Response, it is important to determine when a particular user was active on a system. The logout record can eliminate those users who disconnected, which helps narrow the field.VERBOSE level specifies that login and logout activity as well as the key fingerprint for any SSH key used for login will be logged. This information is important for SSH key management, especially in legacy environments. Rationale: SSH provides several logging levels with varying amounts of verbosity. DEBUG is specifically not recommended other than strictly for debugging SSH communications since it provides so much data that it is difficult to identify important security information. SolutionEdit the /etc/ssh/sshd_config file to set the parameter as follows:LogLevel VERBOSE OR LogLevel INFO Default Value: LogLevel INFO See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sshd -T | /usr/bin/grep -i loglevel' returned :
loglevel INFO lab-preventaThe command '/usr/sbin/sshd -T | /usr/bin/grep -i loglevel' returned :
loglevel INFO 5.3.8 Ensure SSH IgnoreRhosts is enabledInfoThe IgnoreRhosts parameter specifies that .rhosts and .shosts files will not be used in RhostsRSAAuthentication or HostbasedAuthentication.Rationale: Setting this parameter forces users to enter a password when authenticating with ssh. SolutionEdit the /etc/ssh/sshd_config file to set the parameter as follows:IgnoreRhosts yes Default Value: IgnoreRhosts yes See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sshd -T | /usr/bin/grep -P -i '^[\s]*IgnoreRhosts[\s]'' returned :
ignorerhosts yes lab-preventaThe command '/usr/sbin/sshd -T | /usr/bin/grep -P -i '^[\s]*IgnoreRhosts[\s]'' returned :
ignorerhosts yes 5.3.9 Ensure SSH HostbasedAuthentication is disabledInfoThe HostbasedAuthentication parameter specifies if authentication is allowed through trusted hosts via the user of .rhosts, or /etc/hosts.equiv, along with successful public key client host authentication. This option only applies to SSH Protocol Version 2.Rationale: Even though the .rhosts files are ineffective if support is disabled in /etc/pam.conf, disabling the ability to use .rhosts files in SSH provides an additional layer of protection. SolutionEdit the /etc/ssh/sshd_config file to set the parameter as follows:HostbasedAuthentication no Default Value: HostbasedAuthentication no See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/sshd -T | /usr/bin/grep -P -i '^[\s]*HostbasedAuthentication[\s]'' returned :
hostbasedauthentication no lab-preventaThe command '/usr/sbin/sshd -T | /usr/bin/grep -P -i '^[\s]*HostbasedAuthentication[\s]'' returned :
hostbasedauthentication no 5.4.1 Ensure password creation requirements are configured - password-auth retry=3InfoThe pam_pwquality.so module checks the strength of passwords. It performs checks such as making sure a password is not a dictionary word, it is a certain length, contains a mix of characters (e.g. alphabet, numeric, other) and more. The following are definitions of the pam_pwquality.so options.The following options are set in the /etc/security/pwquality.conf file: Password Length: minlen = 14 - password must be 14 characters or more Password complexity: minclass = 4 - The minimum number of required classes of characters for the new password (digits, uppercase, lowercase, others) OR dcredit = -1 - provide at least one digit ucredit = -1 - provide at least one uppercase character ocredit = -1 - provide at least one special character lcredit = -1 - provide at least one lowercase character The following is set in the /etc/pam.d/password-auth and /etc/pam.d/system-auth files try_first_pass - retrieve the password from a previous stacked PAM module. If not available, then prompt the user for a password. retry=3 - Allow 3 tries before sending back a failure. The settings shown above are one possible policy. Alter these values to conform to your own organization's password policies. Notes: Settings in /etc/security/pwquality.conf must use spaces around the = symbol. Additional modules options may be set in the /etc/pam.d/password-auth and /etc/pam.d/system-auth files Rationale: Strong passwords and limited attempts before locking an account protect systems from being hacked through brute force methods. SolutionEdit the file /etc/security/pwquality.conf and add or modify the following line for password length to conform to site policyminlen = 14 Edit the file /etc/security/pwquality.conf and add or modify the following line for password complexity to conform to site policy minclass = 4 OR dcredit = -1 ucredit = -1 ocredit = -1 lcredit = -1 Edit the /etc/pam.d/password-auth and /etc/pam.d/system-auth files to include the appropriate options for pam_pwquality.so and to conform to site policy: password requisite pam_pwquality.so try_first_pass retry=3 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaCompliant file(s):
/etc/pam.d/password-auth - regex '^[\s]*password[\s]+(requisite|required)[\s]+pam_pwquality\.so[\s]' found - expect '[\s]+retry[\s]*=[\s]*[1-3]' found in the following lines: 15: password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= lab-preventaCompliant file(s):
/etc/pam.d/password-auth - regex '^[\s]*password[\s]+(requisite|required)[\s]+pam_pwquality\.so[\s]' found - expect '[\s]+retry[\s]*=[\s]*[1-3]' found in the following lines: 15: password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= 5.4.1 Ensure password creation requirements are configured - password-auth try_first_passInfoThe pam_pwquality.so module checks the strength of passwords. It performs checks such as making sure a password is not a dictionary word, it is a certain length, contains a mix of characters (e.g. alphabet, numeric, other) and more. The following are definitions of the pam_pwquality.so options.The following options are set in the /etc/security/pwquality.conf file: Password Length: minlen = 14 - password must be 14 characters or more Password complexity: minclass = 4 - The minimum number of required classes of characters for the new password (digits, uppercase, lowercase, others) OR dcredit = -1 - provide at least one digit ucredit = -1 - provide at least one uppercase character ocredit = -1 - provide at least one special character lcredit = -1 - provide at least one lowercase character The following is set in the /etc/pam.d/password-auth and /etc/pam.d/system-auth files try_first_pass - retrieve the password from a previous stacked PAM module. If not available, then prompt the user for a password. retry=3 - Allow 3 tries before sending back a failure. The settings shown above are one possible policy. Alter these values to conform to your own organization's password policies. Notes: Settings in /etc/security/pwquality.conf must use spaces around the = symbol. Additional modules options may be set in the /etc/pam.d/password-auth and /etc/pam.d/system-auth files Rationale: Strong passwords and limited attempts before locking an account protect systems from being hacked through brute force methods. SolutionEdit the file /etc/security/pwquality.conf and add or modify the following line for password length to conform to site policyminlen = 14 Edit the file /etc/security/pwquality.conf and add or modify the following line for password complexity to conform to site policy minclass = 4 OR dcredit = -1 ucredit = -1 ocredit = -1 lcredit = -1 Edit the /etc/pam.d/password-auth and /etc/pam.d/system-auth files to include the appropriate options for pam_pwquality.so and to conform to site policy: password requisite pam_pwquality.so try_first_pass retry=3 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaCompliant file(s):
/etc/pam.d/password-auth - regex '^[\s]*password[\s]+(requisite|required)[\s]+pam_pwquality\.so[\s]' found - expect 'try_first_pass' found in the following lines: 15: password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= lab-preventaCompliant file(s):
/etc/pam.d/password-auth - regex '^[\s]*password[\s]+(requisite|required)[\s]+pam_pwquality\.so[\s]' found - expect 'try_first_pass' found in the following lines: 15: password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= 5.4.1 Ensure password creation requirements are configured - system-auth retry=3InfoThe pam_pwquality.so module checks the strength of passwords. It performs checks such as making sure a password is not a dictionary word, it is a certain length, contains a mix of characters (e.g. alphabet, numeric, other) and more. The following are definitions of the pam_pwquality.so options.The following options are set in the /etc/security/pwquality.conf file: Password Length: minlen = 14 - password must be 14 characters or more Password complexity: minclass = 4 - The minimum number of required classes of characters for the new password (digits, uppercase, lowercase, others) OR dcredit = -1 - provide at least one digit ucredit = -1 - provide at least one uppercase character ocredit = -1 - provide at least one special character lcredit = -1 - provide at least one lowercase character The following is set in the /etc/pam.d/password-auth and /etc/pam.d/system-auth files try_first_pass - retrieve the password from a previous stacked PAM module. If not available, then prompt the user for a password. retry=3 - Allow 3 tries before sending back a failure. The settings shown above are one possible policy. Alter these values to conform to your own organization's password policies. Notes: Settings in /etc/security/pwquality.conf must use spaces around the = symbol. Additional modules options may be set in the /etc/pam.d/password-auth and /etc/pam.d/system-auth files Rationale: Strong passwords and limited attempts before locking an account protect systems from being hacked through brute force methods. SolutionEdit the file /etc/security/pwquality.conf and add or modify the following line for password length to conform to site policyminlen = 14 Edit the file /etc/security/pwquality.conf and add or modify the following line for password complexity to conform to site policy minclass = 4 OR dcredit = -1 ucredit = -1 ocredit = -1 lcredit = -1 Edit the /etc/pam.d/password-auth and /etc/pam.d/system-auth files to include the appropriate options for pam_pwquality.so and to conform to site policy: password requisite pam_pwquality.so try_first_pass retry=3 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaCompliant file(s):
/etc/pam.d/system-auth - regex '^[\s]*password[\s]+(requisite|required)[\s]+pam_pwquality\.so[\s]' found - expect '[\s]+retry[\s]*=[\s]*[1-3]' found in the following lines: 15: password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= lab-preventaCompliant file(s):
/etc/pam.d/system-auth - regex '^[\s]*password[\s]+(requisite|required)[\s]+pam_pwquality\.so[\s]' found - expect '[\s]+retry[\s]*=[\s]*[1-3]' found in the following lines: 15: password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= 5.4.1 Ensure password creation requirements are configured - system-auth try_first_passInfoThe pam_pwquality.so module checks the strength of passwords. It performs checks such as making sure a password is not a dictionary word, it is a certain length, contains a mix of characters (e.g. alphabet, numeric, other) and more. The following are definitions of the pam_pwquality.so options.The following options are set in the /etc/security/pwquality.conf file: Password Length: minlen = 14 - password must be 14 characters or more Password complexity: minclass = 4 - The minimum number of required classes of characters for the new password (digits, uppercase, lowercase, others) OR dcredit = -1 - provide at least one digit ucredit = -1 - provide at least one uppercase character ocredit = -1 - provide at least one special character lcredit = -1 - provide at least one lowercase character The following is set in the /etc/pam.d/password-auth and /etc/pam.d/system-auth files try_first_pass - retrieve the password from a previous stacked PAM module. If not available, then prompt the user for a password. retry=3 - Allow 3 tries before sending back a failure. The settings shown above are one possible policy. Alter these values to conform to your own organization's password policies. Notes: Settings in /etc/security/pwquality.conf must use spaces around the = symbol. Additional modules options may be set in the /etc/pam.d/password-auth and /etc/pam.d/system-auth files Rationale: Strong passwords and limited attempts before locking an account protect systems from being hacked through brute force methods. SolutionEdit the file /etc/security/pwquality.conf and add or modify the following line for password length to conform to site policyminlen = 14 Edit the file /etc/security/pwquality.conf and add or modify the following line for password complexity to conform to site policy minclass = 4 OR dcredit = -1 ucredit = -1 ocredit = -1 lcredit = -1 Edit the /etc/pam.d/password-auth and /etc/pam.d/system-auth files to include the appropriate options for pam_pwquality.so and to conform to site policy: password requisite pam_pwquality.so try_first_pass retry=3 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaCompliant file(s):
/etc/pam.d/system-auth - regex '^[\s]*password[\s]+(requisite|required)[\s]+pam_pwquality\.so[\s]' found - expect 'try_first_pass' found in the following lines: 15: password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= lab-preventaCompliant file(s):
/etc/pam.d/system-auth - regex '^[\s]*password[\s]+(requisite|required)[\s]+pam_pwquality\.so[\s]' found - expect 'try_first_pass' found in the following lines: 15: password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= 5.4.2 Ensure lockout for failed password attempts is configured - password-auth 'auth sufficient pam_unix.so'InfoLock out users after n unsuccessful consecutive login attempts.These settings are commonly configured with the pam_faillock.so module. Some environments may continue using the pam_tally2.so module, where this older method may simplify automation in mixed environments. Set the lockout number in deny= to the policy in effect at your site. unlock_time=_n_ is the number of seconds the account remains locked after the number of attempts configured in deny=_n_ has been met. Notes: Additional module options may be set, recommendation only covers those listed here. When modifying authentication configuration using the authconfig utility, the system-auth and password-auth files are overwritten with the settings from the authconfig utility. This can be avoided by creating symbolic links in place of the configuration files, which authconfig recognizes and does not overwrite. These symbolic links are the default for Fedora 19 derived distributions. Use of the 'audit' keyword may log credentials in the case of user error during authentication. This risk should be evaluated in the context of the site policies of your organization. If a user has been locked out because they have reached the maximum consecutive failure count defined by deny= in the pam_faillock.so or the pam_tally2.so module, the user can be unlocked by issuing following commands. This command sets the failed count to 0, effectively unlocking the user. If pam_faillock.so is used: # faillock --user <username> --reset If pam_tally2.so is used: # pam_tally2 -u <username> --reset Rationale: Locking out user IDs after n unsuccessful consecutive login attempts mitigates brute force password attacks against your systems. SolutionEdit the files /etc/pam.d/system-auth and /etc/pam.d/password-auth and add the following lines:Modify the deny= and unlock_time= parameters to conform to local site policy, Not to be greater than deny=5 To use pam_faillock.so module, add the following lines to the auth section: auth required pam_faillock.so preauth silent audit deny=5 unlock_time=900 auth [default=die] pam_faillock.so authfail audit deny=5 unlock_time=900 The auth sections should look similar to the following example: Note: The ordering on the lines in the auth section is important. The preauth line needs to below the line auth required pam_env.so and above all password validation lines. The authfail line needs to be after all password validation lines such as pam_sss.so. Incorrect order can cause you to be locked out of the system Example: auth required pam_env.so auth required pam_faillock.so preauth silent audit deny=5 unlock_time=900 # <- Under 'auth required pam_env.so' auth sufficient pam_unix.so nullok try_first_pass auth [default=die] pam_faillock.so authfail audit deny=5 unlock_time=900 # <- Last auth line before 'auth requisite pam_succeed_if.so' auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth required pam_deny.so Add the following line to the account section: account required pam_faillock.so Example: account required pam_faillock.so account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_pam_succeed_if.so uid < 1000 quiet account required pam_permit.so OR To use the pam_tally2.so module, add the following line to the auth section: auth required pam_tally2.so deny=5 onerr=fail unlock_time=900 The auth sections should look similar to the following example: Note: The ordering on the lines in the auth section is important. the additional line needs to below the line auth required pam_env.so and above all password validation lines. Example: auth required pam_env.so auth required pam_tally2.so deny=5 onerr=fail unlock_time=900 # <- Under 'auth required pam_env.so' auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth required pam_deny.so Add the following line to the account section: account required pam_tally2.so Example: account required pam_tally2.so account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_pam_succeed_if.so uid < 1000 quiet account required pam_permit.so See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaCompliant file(s):
/etc/pam.d/password-auth - regex '^[\s]*auth[\s]+sufficient[\s]+pam_unix.so[\s]+' found - expect '^[\s]*auth[\s]+sufficient[\s]+pam_unix.so[\s]+.*try_first_pass[\s]*$' found in the following lines: 6: auth sufficient pam_unix.so nullok try_first_pass lab-preventaCompliant file(s):
/etc/pam.d/password-auth - regex '^[\s]*auth[\s]+sufficient[\s]+pam_unix.so[\s]+' found - expect '^[\s]*auth[\s]+sufficient[\s]+pam_unix.so[\s]+.*try_first_pass[\s]*$' found in the following lines: 6: auth sufficient pam_unix.so nullok try_first_pass 5.4.2 Ensure lockout for failed password attempts is configured - system-auth 'auth sufficient pam_unix.so'InfoLock out users after n unsuccessful consecutive login attempts.These settings are commonly configured with the pam_faillock.so module. Some environments may continue using the pam_tally2.so module, where this older method may simplify automation in mixed environments. Set the lockout number in deny= to the policy in effect at your site. unlock_time=_n_ is the number of seconds the account remains locked after the number of attempts configured in deny=_n_ has been met. Notes: Additional module options may be set, recommendation only covers those listed here. When modifying authentication configuration using the authconfig utility, the system-auth and password-auth files are overwritten with the settings from the authconfig utility. This can be avoided by creating symbolic links in place of the configuration files, which authconfig recognizes and does not overwrite. These symbolic links are the default for Fedora 19 derived distributions. Use of the 'audit' keyword may log credentials in the case of user error during authentication. This risk should be evaluated in the context of the site policies of your organization. If a user has been locked out because they have reached the maximum consecutive failure count defined by deny= in the pam_faillock.so or the pam_tally2.so module, the user can be unlocked by issuing following commands. This command sets the failed count to 0, effectively unlocking the user. If pam_faillock.so is used: # faillock --user <username> --reset If pam_tally2.so is used: # pam_tally2 -u <username> --reset Rationale: Locking out user IDs after n unsuccessful consecutive login attempts mitigates brute force password attacks against your systems. SolutionEdit the files /etc/pam.d/system-auth and /etc/pam.d/password-auth and add the following lines:Modify the deny= and unlock_time= parameters to conform to local site policy, Not to be greater than deny=5 To use pam_faillock.so module, add the following lines to the auth section: auth required pam_faillock.so preauth silent audit deny=5 unlock_time=900 auth [default=die] pam_faillock.so authfail audit deny=5 unlock_time=900 The auth sections should look similar to the following example: Note: The ordering on the lines in the auth section is important. The preauth line needs to below the line auth required pam_env.so and above all password validation lines. The authfail line needs to be after all password validation lines such as pam_sss.so. Incorrect order can cause you to be locked out of the system Example: auth required pam_env.so auth required pam_faillock.so preauth silent audit deny=5 unlock_time=900 # <- Under 'auth required pam_env.so' auth sufficient pam_unix.so nullok try_first_pass auth [default=die] pam_faillock.so authfail audit deny=5 unlock_time=900 # <- Last auth line before 'auth requisite pam_succeed_if.so' auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth required pam_deny.so Add the following line to the account section: account required pam_faillock.so Example: account required pam_faillock.so account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_pam_succeed_if.so uid < 1000 quiet account required pam_permit.so OR To use the pam_tally2.so module, add the following line to the auth section: auth required pam_tally2.so deny=5 onerr=fail unlock_time=900 The auth sections should look similar to the following example: Note: The ordering on the lines in the auth section is important. the additional line needs to below the line auth required pam_env.so and above all password validation lines. Example: auth required pam_env.so auth required pam_tally2.so deny=5 onerr=fail unlock_time=900 # <- Under 'auth required pam_env.so' auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth required pam_deny.so Add the following line to the account section: account required pam_tally2.so Example: account required pam_tally2.so account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_pam_succeed_if.so uid < 1000 quiet account required pam_permit.so See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaCompliant file(s):
/etc/pam.d/system-auth - regex '^[\s]*auth[\s]+sufficient[\s]+pam_unix.so[\s]+' found - expect '^[\s]*auth[\s]+sufficient[\s]+pam_unix.so[\s]+.*try_first_pass[\s]*$' found in the following lines: 6: auth sufficient pam_unix.so nullok try_first_pass lab-preventaCompliant file(s):
/etc/pam.d/system-auth - regex '^[\s]*auth[\s]+sufficient[\s]+pam_unix.so[\s]+' found - expect '^[\s]*auth[\s]+sufficient[\s]+pam_unix.so[\s]+.*try_first_pass[\s]*$' found in the following lines: 6: auth sufficient pam_unix.so nullok try_first_pass 5.4.3 Ensure password hashing algorithm is SHA-512 - password-authInfoThe commands below change password encryption from md5 to sha512 (a much stronger hashing algorithm). All existing accounts will need to perform a password change to upgrade the stored hashes to the new algorithm.Note: These changes only apply to accounts configured on the local system. Additional module options may be set, recommendation only covers those listed here. Rationale: The SHA-512 algorithm provides much stronger hashing than MD5, thus providing additional protection to the system by increasing the level of effort for an attacker to successfully determine passwords. SolutionEdit the /etc/pam.d/password-auth and /etc/pam.d/system-auth files to include sha512 option and remove the md5 option for pam_unix.so:password sufficient pam_unix.so sha512 Note: Any system accounts that need to be expired should be carefully done separately by the system administrator to prevent any potential problems. If it is determined that the password algorithm being used is not SHA-512, once it is changed, it is recommended that all user ID's be immediately expired and forced to change their passwords on next login, In accordance with local site policies. To accomplish this, the following command can be used. This command intentionally does not affect the root account. The root account's password will also need to be changed. # awk -F: '( $3<''$(awk '/^s*UID_MIN/{print $2}' /etc/login.defs)'' && $1 !~ /^(nfs)?nobody$/ && $1 != 'root' ) { print $1 }' /etc/passwd | xargs -n 1 chage -d 0 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaCompliant file(s):
/etc/pam.d/password-auth - regex '^[\s]*password[\s]+sufficient[\s]+pam_unix\.so[\s]*' found - expect 'sha512' found in the following lines: 16: password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok lab-preventaCompliant file(s):
/etc/pam.d/password-auth - regex '^[\s]*password[\s]+sufficient[\s]+pam_unix\.so[\s]*' found - expect 'sha512' found in the following lines: 16: password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok 5.4.3 Ensure password hashing algorithm is SHA-512 - system-authInfoThe commands below change password encryption from md5 to sha512 (a much stronger hashing algorithm). All existing accounts will need to perform a password change to upgrade the stored hashes to the new algorithm.Note: These changes only apply to accounts configured on the local system. Additional module options may be set, recommendation only covers those listed here. Rationale: The SHA-512 algorithm provides much stronger hashing than MD5, thus providing additional protection to the system by increasing the level of effort for an attacker to successfully determine passwords. SolutionEdit the /etc/pam.d/password-auth and /etc/pam.d/system-auth files to include sha512 option and remove the md5 option for pam_unix.so:password sufficient pam_unix.so sha512 Note: Any system accounts that need to be expired should be carefully done separately by the system administrator to prevent any potential problems. If it is determined that the password algorithm being used is not SHA-512, once it is changed, it is recommended that all user ID's be immediately expired and forced to change their passwords on next login, In accordance with local site policies. To accomplish this, the following command can be used. This command intentionally does not affect the root account. The root account's password will also need to be changed. # awk -F: '( $3<''$(awk '/^s*UID_MIN/{print $2}' /etc/login.defs)'' && $1 !~ /^(nfs)?nobody$/ && $1 != 'root' ) { print $1 }' /etc/passwd | xargs -n 1 chage -d 0 See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaCompliant file(s):
/etc/pam.d/system-auth - regex '^[\s]*password[\s]+sufficient[\s]+pam_unix\.so[\s]*' found - expect 'sha512' found in the following lines: 16: password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok lab-preventaCompliant file(s):
/etc/pam.d/system-auth - regex '^[\s]*password[\s]+sufficient[\s]+pam_unix\.so[\s]*' found - expect 'sha512' found in the following lines: 16: password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok 5.5.1.3 Ensure password expiration warning days is 7 or more - login.defsInfoThe PASS_WARN_AGE parameter in /etc/login.defs allows an administrator to notify users that their password will expire in a defined number of days. It is recommended that the PASS_WARN_AGE parameter be set to 7 or more days.Rationale: Providing an advance warning that a password will be expiring gives users time to think of a secure password. Users caught unaware may choose a simple password or write it down where it may be discovered. SolutionSet the PASS_WARN_AGE parameter to 7 in /etc/login.defs :PASS_WARN_AGE 7 Modify user parameters for all users with a password set to match: # chage --warndays 7 <user> See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaCompliant file(s):
/etc/login.defs - regex '^[\s]*PASS_WARN_AGE[\s]+' found - expect '^[\s]*PASS_WARN_AGE[\s]+([7-9]|[1-9][0-9]+)[\s]*$' found in the following lines: 28: PASS_WARN_AGE 7 lab-preventaCompliant file(s):
/etc/login.defs - regex '^[\s]*PASS_WARN_AGE[\s]+' found - expect '^[\s]*PASS_WARN_AGE[\s]+([7-9]|[1-9][0-9]+)[\s]*$' found in the following lines: 28: PASS_WARN_AGE 7 5.5.1.3 Ensure password expiration warning days is 7 or more - usersInfoThe PASS_WARN_AGE parameter in /etc/login.defs allows an administrator to notify users that their password will expire in a defined number of days. It is recommended that the PASS_WARN_AGE parameter be set to 7 or more days.Rationale: Providing an advance warning that a password will be expiring gives users time to think of a secure password. Users caught unaware may choose a simple password or write it down where it may be discovered. SolutionSet the PASS_WARN_AGE parameter to 7 in /etc/login.defs :PASS_WARN_AGE 7 Modify user parameters for all users with a password set to match: # chage --warndays 7 <user> See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaCompliant file(s):
/etc/shadow - regex '^[^:]+:[^!*]' found - expect '^([^:]*:){5}([7-9]|[1-9][0-9]+):' found in the following lines: 1: root:$6$VGyBibZp.jE4gn93$w72KJba0CBCKz.5mcjokPGnbgio.oq.GdALX8UniF.HppYLQqsfULaoIK0s4U3H2rz/xEwTXdIN7aJwvnxbG41::0:99999:7::: 20: admin:$6$/WfmeNEcZ8ESDkhI$AI3AqWU1ZPpzcd5qJL/rj6LN1FDyb6olJctlOOiyRZf8Ss/pJxLvxy0V95j8b/w9qhDP/gnPk.curbLouYUGw/::0:99999:7::: lab-preventaCompliant file(s):
/etc/shadow - regex '^[^:]+:[^!*]' found - expect '^([^:]*:){5}([7-9]|[1-9][0-9]+):' found in the following lines: 1: root:$6$VGyBibZp.jE4gn93$w72KJba0CBCKz.5mcjokPGnbgio.oq.GdALX8UniF.HppYLQqsfULaoIK0s4U3H2rz/xEwTXdIN7aJwvnxbG41::0:99999:7::: 20: admin:$6$/WfmeNEcZ8ESDkhI$AI3AqWU1ZPpzcd5qJL/rj6LN1FDyb6olJctlOOiyRZf8Ss/pJxLvxy0V95j8b/w9qhDP/gnPk.curbLouYUGw/::0:99999:7::: 5.5.1.5 Ensure all users last password change date is in the pastInfoAll users should have a password change date in the past.Rationale: If a users recorded password change date is in the future then they could bypass any set password expiration. SolutionInvestigate any users with a password change date in the future and correct them. Locking the account, expiring the password, or resetting the password manually may be appropriate.See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command 'echo 'Username, Current Days, Last Password Change Days'; output=""; failures=0; for i in $(cut -d: -f1 < /etc/shadow); do now=$(($(date +%s) / 86400)); change_date=$(chage --list "$i" | grep 'Last password change' | cut -d: -f2 | awk '{$1=$1};1'); if [[ $change_date != "never" ]]; then epoch_change_date=$(($(date -d "${change_date}" +%s) / 86400)); else epoch_change_date='Never'; fi; output="${i}, ${now}, ${epoch_change_date}"; if [[ $epoch_change_date -le $now ]]; then output="${output} - Pass"; else output="${output} - Fail"; ((failures++)); fi; echo "${output}"; done; echo "Number of failures: ${failures}"' returned :
Username, Current Days, Last Password Change Days root, 19654, Never - Pass bin, 19654, 18353 - Pass daemon, 19654, 18353 - Pass adm, 19654, 18353 - Pass lp, 19654, 18353 - Pass sync, 19654, 18353 - Pass shutdown, 19654, 18353 - Pass halt, 19654, 18353 - Pass mail, 19654, 18353 - Pass operator, 19654, 18353 - Pass games, 19654, 18353 - Pass ftp, 19654, 18353 - Pass nobody, 19654, 18353 - Pass systemd-network, 19654, 19550 - Pass dbus, 19654, 19550 - Pass polkitd, 19654, 19550 - Pass tss, 19654, 19550 - Pass sshd, 19654, 19550 - Pass postfix, 19654, 19550 - Pass admin, 19654, Never - Pass Number of failures: 0 lab-preventaThe command 'echo 'Username, Current Days, Last Password Change Days'; output=""; failures=0; for i in $(cut -d: -f1 < /etc/shadow); do now=$(($(date +%s) / 86400)); change_date=$(chage --list "$i" | grep 'Last password change' | cut -d: -f2 | awk '{$1=$1};1'); if [[ $change_date != "never" ]]; then epoch_change_date=$(($(date -d "${change_date}" +%s) / 86400)); else epoch_change_date='Never'; fi; output="${i}, ${now}, ${epoch_change_date}"; if [[ $epoch_change_date -le $now ]]; then output="${output} - Pass"; else output="${output} - Fail"; ((failures++)); fi; echo "${output}"; done; echo "Number of failures: ${failures}"' returned :
Username, Current Days, Last Password Change Days root, 19654, Never - Pass bin, 19654, 18353 - Pass daemon, 19654, 18353 - Pass adm, 19654, 18353 - Pass lp, 19654, 18353 - Pass sync, 19654, 18353 - Pass shutdown, 19654, 18353 - Pass halt, 19654, 18353 - Pass mail, 19654, 18353 - Pass operator, 19654, 18353 - Pass games, 19654, 18353 - Pass ftp, 19654, 18353 - Pass nobody, 19654, 18353 - Pass systemd-network, 19654, 19550 - Pass dbus, 19654, 19550 - Pass polkitd, 19654, 19550 - Pass tss, 19654, 19550 - Pass sshd, 19654, 19550 - Pass postfix, 19654, 19550 - Pass admin, 19654, Never - Pass Number of failures: 0 5.5.2 Ensure system accounts are secured - non-login shellInfoThere are a number of accounts provided with most distributions that are used to manage applications and are not intended to provide an interactive shell.Rationale: It is important to make sure that accounts that are not being used by regular users are prevented from being used to provide an interactive shell. By default, most distributions set the password field for these accounts to an invalid string, but it is also recommended that the shell field in the password file be set to the nologin shell. This prevents the account from potentially being used to run any commands. Note: The root, sync, shutdown, and halt users are exempted from requiring a non-login shell. SolutionRun the commands appropriate for your distribution:Set the shell for any accounts returned by the audit to nologin: # usermod -s $(which nologin) <user> Lock any non root accounts returned by the audit: # usermod -L <user> The following command will set all system accounts to a non login shell: awk -F: '($1!='root' && $1!='sync' && $1!='shutdown' && $1!='halt' && $1!~/^+/ && $3<''$(awk '/^s*UID_MIN/{print $2}' /etc/login.defs)'' && $7!='''$(which nologin)''' && $7!='/bin/false' && $7!='/usr/bin/false') {print $1}' /etc/passwd | while read -r user; do usermod -s '$(which nologin)' '$user'; done The following command will automatically lock not root system accounts: awk -F: '($1!='root' && $1!~/^+/ && $3<''$(awk '/^s*UID_MIN/{print $2}' /etc/login.defs)'') {print $1}' /etc/passwd | xargs -I '{}' passwd -S '{}' | awk '($2!='L' && $2!='LK') {print $1}' | while read -r user; do usermod -L '$user'; done See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/awk -F: '($1!="root" && $1!="sync" && $1!="shutdown" && $1!="halt" && $1!~/^\+/ && $3<'"$(/usr/bin/awk '/^\s*UID_MIN/{print $2}' /etc/login.defs)"' && $7!~"'"(/usr)?/sbin/nologin"'" && $7!="/bin/false" && $7!="/usr/bin/false") {print}' /etc/passwd | /bin/awk '{print} END {if (NR == 0) print "pass" ; else print "fail"}'' returned :
pass lab-preventaThe command '/usr/bin/awk -F: '($1!="root" && $1!="sync" && $1!="shutdown" && $1!="halt" && $1!~/^\+/ && $3<'"$(/usr/bin/awk '/^\s*UID_MIN/{print $2}' /etc/login.defs)"' && $7!~"'"(/usr)?/sbin/nologin"'" && $7!="/bin/false" && $7!="/usr/bin/false") {print}' /etc/passwd | /bin/awk '{print} END {if (NR == 0) print "pass" ; else print "fail"}'' returned :
pass 5.5.2 Ensure system accounts are secured - unlocked non-rootInfoThere are a number of accounts provided with most distributions that are used to manage applications and are not intended to provide an interactive shell.Rationale: It is important to make sure that accounts that are not being used by regular users are prevented from being used to provide an interactive shell. By default, most distributions set the password field for these accounts to an invalid string, but it is also recommended that the shell field in the password file be set to the nologin shell. This prevents the account from potentially being used to run any commands. Note: The root, sync, shutdown, and halt users are exempted from requiring a non-login shell. SolutionRun the commands appropriate for your distribution:Set the shell for any accounts returned by the audit to nologin: # usermod -s $(which nologin) <user> Lock any non root accounts returned by the audit: # usermod -L <user> The following command will set all system accounts to a non login shell: awk -F: '($1!='root' && $1!='sync' && $1!='shutdown' && $1!='halt' && $1!~/^+/ && $3<''$(awk '/^s*UID_MIN/{print $2}' /etc/login.defs)'' && $7!='''$(which nologin)''' && $7!='/bin/false' && $7!='/usr/bin/false') {print $1}' /etc/passwd | while read -r user; do usermod -s '$(which nologin)' '$user'; done The following command will automatically lock not root system accounts: awk -F: '($1!='root' && $1!~/^+/ && $3<''$(awk '/^s*UID_MIN/{print $2}' /etc/login.defs)'') {print $1}' /etc/passwd | xargs -I '{}' passwd -S '{}' | awk '($2!='L' && $2!='LK') {print $1}' | while read -r user; do usermod -L '$user'; done See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/awk -F: '($1!="root" && $1!~/^\+/ && $3<'"$(/usr/bin/awk '/^\s*UID_MIN/{print $2}' /etc/login.defs)"') {print $1}' /etc/passwd | /usr/bin/xargs -I '{}' passwd -S '{}' | /usr/bin/awk '($2!="L" && $2!="LK") {print $1}' | /usr/bin/awk '{print} END {if (NR == 0) print "pass" ; else print "fail"}'' returned :
pass lab-preventaThe command '/usr/bin/awk -F: '($1!="root" && $1!~/^\+/ && $3<'"$(/usr/bin/awk '/^\s*UID_MIN/{print $2}' /etc/login.defs)"') {print $1}' /etc/passwd | /usr/bin/xargs -I '{}' passwd -S '{}' | /usr/bin/awk '($2!="L" && $2!="LK") {print $1}' | /usr/bin/awk '{print} END {if (NR == 0) print "pass" ; else print "fail"}'' returned :
pass 5.5.3 Ensure default group for the root account is GID 0InfoThe usermod command can be used to specify which group the root user belongs to. This affects permissions of files that are created by the root user.Rationale: Using GID 0 for the root account helps prevent root -owned files from accidentally becoming accessible to non-privileged users. SolutionRun the following command to set the root user default group to GID 0 :# usermod -g 0 root See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaCompliant file(s):
/etc/passwd - regex '^root:' found - expect '^root:x:0:0:' found in the following lines: 1: root:x:0:0:root:/root:/bin/bash lab-preventaCompliant file(s):
/etc/passwd - regex '^root:' found - expect '^root:x:0:0:' found in the following lines: 1: root:x:0:0:root:/root:/bin/bash 6.1.2 Ensure permissions on /etc/passwd are configuredInfoThe /etc/passwd file contains user account information that is used by many system utilities and therefore must be readable for these utilities to operate.Rationale: It is critical to ensure that the /etc/passwd file is protected from unauthorized write access. Although it is protected by default, the file permissions could be changed either inadvertently or through malicious actions. SolutionRun the following commands to set owner, group, and permissions on /etc/passwd :# chown root:root /etc/passwd # chmod u-x,g-wx,o-wx /etc/passwd See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe file /etc/passwd with fmode owner: root group: root mode: 0644 uid: 0 gid: 0 uneven permissions : FALSE is compliant with the policy value
/etc/passwd lab-preventaThe file /etc/passwd with fmode owner: root group: root mode: 0644 uid: 0 gid: 0 uneven permissions : FALSE is compliant with the policy value
/etc/passwd 6.1.3 Ensure permissions on /etc/passwd- are configuredInfoThe /etc/passwd- file contains backup user account information.Rationale: It is critical to ensure that the /etc/passwd- file is protected from unauthorized access. Although it is protected by default, the file permissions could be changed either inadvertently or through malicious actions. SolutionRun the following commands to set owner, group, and permissions on /etc/passwd- :# chown root:root /etc/passwd- # chmod u-x,go-wx /etc/passwd- See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe file /etc/passwd- with fmode owner: root group: root mode: 0644 uid: 0 gid: 0 uneven permissions : FALSE is compliant with the policy value
/etc/passwd- lab-preventaThe file /etc/passwd- with fmode owner: root group: root mode: 0644 uid: 0 gid: 0 uneven permissions : FALSE is compliant with the policy value
/etc/passwd- 6.1.4 Ensure permissions on /etc/shadow are configuredInfoThe /etc/shadow file is used to store the information about user accounts that is critical to the security of those accounts, such as the hashed password and other security information.Rationale: If attackers can gain read access to the /etc/shadow file, they can easily run a password cracking program against the hashed password to break it. Other security information that is stored in the /etc/shadow file (such as expiration) could also be useful to subvert the user accounts. SolutionRun the following commands to set owner, group, and permissions on /etc/shadow :# chown root:root /etc/shadow # chmod 0000 /etc/shadow See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe file /etc/shadow with fmode owner: root group: root mode: 0000 uid: 0 gid: 0 uneven permissions : FALSE is compliant with the policy value
/etc/shadow lab-preventaThe file /etc/shadow with fmode owner: root group: root mode: 0000 uid: 0 gid: 0 uneven permissions : FALSE is compliant with the policy value
/etc/shadow 6.1.5 Ensure permissions on /etc/shadow- are configuredInfoThe /etc/shadow- file is used to store backup information about user accounts that is critical to the security of those accounts, such as the hashed password and other security information.Rationale: It is critical to ensure that the /etc/shadow- file is protected from unauthorized access. Although it is protected by default, the file permissions could be changed either inadvertently or through malicious actions. SolutionRun the following commands to set owner, group, and permissions on /etc/shadow- :# chown root:root /etc/shadow- # chmod 0000 /etc/shadow- See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe file /etc/shadow- with fmode owner: root group: root mode: 0000 uid: 0 gid: 0 uneven permissions : FALSE is compliant with the policy value
/etc/shadow- lab-preventaThe file /etc/shadow- with fmode owner: root group: root mode: 0000 uid: 0 gid: 0 uneven permissions : FALSE is compliant with the policy value
/etc/shadow- 6.1.6 Ensure permissions on /etc/gshadow- are configuredInfoThe /etc/gshadow- file is used to store backup information about groups that is critical to the security of those accounts, such as the hashed password and other security information.Rationale: It is critical to ensure that the /etc/gshadow- file is protected from unauthorized access. Although it is protected by default, the file permissions could be changed either inadvertently or through malicious actions. SolutionRun the following commands to set owner, group, and permissions on /etc/gshadow- :# chown root:root /etc/gshadow- # chmod 0000 /etc/gshadow- See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe file /etc/gshadow- with fmode owner: root group: root mode: 0000 uid: 0 gid: 0 uneven permissions : FALSE is compliant with the policy value
/etc/gshadow- lab-preventaThe file /etc/gshadow- with fmode owner: root group: root mode: 0000 uid: 0 gid: 0 uneven permissions : FALSE is compliant with the policy value
/etc/gshadow- 6.1.7 Ensure permissions on /etc/gshadow are configuredInfoThe /etc/gshadow file is used to store the information about groups that is critical to the security of those accounts, such as the hashed password and other security information.Rationale: If attackers can gain read access to the /etc/gshadow file, they can easily run a password cracking program against the hashed password to break it. Other security information that is stored in the /etc/gshadow file (such as group administrators) could also be useful to subvert the group. SolutionRun the following commands to set owner, group, and permissions on /etc/gshadow :# chown root:root /etc/gshadow # chmod 0000 /etc/gshadow See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe file /etc/gshadow with fmode owner: root group: root mode: 0000 uid: 0 gid: 0 uneven permissions : FALSE is compliant with the policy value
/etc/gshadow lab-preventaThe file /etc/gshadow with fmode owner: root group: root mode: 0000 uid: 0 gid: 0 uneven permissions : FALSE is compliant with the policy value
/etc/gshadow 6.1.8 Ensure permissions on /etc/group are configuredInfoThe /etc/group file contains a list of all the valid groups defined in the system. The command below allows read/write access for root and read access for everyone else.Rationale: The /etc/group file needs to be protected from unauthorized changes by non-privileged users, but needs to be readable as this information is used with many non-privileged programs. SolutionRun the following commands to set owner, group, and permissions on /etc/group :# chown root:root /etc/group # chmod u-x,g-wx,o-wx /etc/group See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe file /etc/group with fmode owner: root group: root mode: 0644 uid: 0 gid: 0 uneven permissions : FALSE is compliant with the policy value
/etc/group lab-preventaThe file /etc/group with fmode owner: root group: root mode: 0644 uid: 0 gid: 0 uneven permissions : FALSE is compliant with the policy value
/etc/group 6.1.9 Ensure permissions on /etc/group- are configuredInfoThe /etc/group- file contains a backup list of all the valid groups defined in the system.Rationale: It is critical to ensure that the /etc/group- file is protected from unauthorized access. Although it is protected by default, the file permissions could be changed either inadvertently or through malicious actions. SolutionRun the following commands to set owner, group, and permissions on /etc/group-:# chown root:root /etc/group- # chmod u-x,go-wx /etc/group- See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe file /etc/group- with fmode owner: root group: root mode: 0644 uid: 0 gid: 0 uneven permissions : FALSE is compliant with the policy value
/etc/group- lab-preventaThe file /etc/group- with fmode owner: root group: root mode: 0644 uid: 0 gid: 0 uneven permissions : FALSE is compliant with the policy value
/etc/group- 6.2.1 Ensure accounts in /etc/passwd use shadowed passwordsInfoLocal accounts can uses shadowed passwords. With shadowed passwords, The passwords are saved in shadow password file, /etc/shadow, encrypted by a salted one-way hash. Accounts with a shadowed password have an x in the second field in /etc/passwd.Rationale: The /etc/passwd file also contains information like user ID's and group ID's that are used by many system programs. Therefore, the /etc/passwd file must remain world readable. In spite of encoding the password with a randomly-generated one-way hash function, an attacker could still break the system if they got access to the /etc/passwd file. This can be mitigated by using shadowed passwords, thus moving the passwords in the /etc/passwd file to /etc/shadow. The /etc/shadow file is set so only root will be able to read and write. This helps mitigate the risk of an attacker gaining access to the encoded passwords with which to perform a dictionary attack. Notes: All accounts must have passwords or be locked to prevent the account from being used by an unauthorized user. A user account with an empty second field in /etc/passwd allows the account to be logged into by providing only the username. SolutionIf any accounts in the /etc/passwd file do not have a single x in the password field, run the following command to set these accounts to use shadowed passwords:# sed -e 's/^([a-zA-Z0-9_]*):[^:]*:/1:x:/' -i /etc/passwd Investigate to determine if the account is logged in and what it is being used for, to determine if it needs to be forced off. See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/awk -F: '($2 != "x" ) { print $1 " is not set to shadowed passwords "}' /etc/passwd | /bin/awk '{print} END {if (NR == 0) print "pass"; else print "fail"}'' returned :
pass lab-preventaThe command '/usr/bin/awk -F: '($2 != "x" ) { print $1 " is not set to shadowed passwords "}' /etc/passwd | /bin/awk '{print} END {if (NR == 0) print "pass"; else print "fail"}'' returned :
pass 6.2.10 Ensure root PATH IntegrityInfoThe root user can execute any command on the system and could be fooled into executing programs unintentionally if the PATH is not set correctly.Rationale: Including the current working directory (.) or other writable directory in root 's executable path makes it likely that an attacker can gain superuser access by forcing an administrator operating as root to execute a Trojan horse program. SolutionCorrect or justify any items discovered in the Audit step.See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaAll of the following must pass to satisfy this requirement:
------------------------- PASSED - Check root path variable $PATH is set to: /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin ------------------------- PASSED - Check writable dirs in root path variable No issues found. lab-preventaAll of the following must pass to satisfy this requirement:
------------------------- PASSED - Check root path variable $PATH is set to: /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin ------------------------- PASSED - Check writable dirs in root path variable No issues found. 6.2.11 Ensure all users' home directories existInfoUsers can be defined in /etc/passwd without a home directory or with a home directory that does not actually exist.Rationale: If the user's home directory does not exist or is unassigned, the user will be placed in '/' and will not be able to write any files or have local environment variables set. SolutionIf any users' home directories do not exist, create them and make sure the respective user owns the directory. Users without an assigned home directory should be removed or assigned a home directory as appropriate.The following script will create a home directory for users with an interactive shell whose home directory doesn't exist: #!/bin/bash awk -F: '($1!~/(halt|sync|shutdown|nfsnobody)/ && $7!~/^(/usr)?/sbin/nologin(/)?$/ && $7!~/(/usr)?/bin/false(/)?$/) { print $1 ' ' $6 }' /etc/passwd | while read -r user dir; do if [ ! -d '$dir' ]; then mkdir '$dir' chmod g-w,o-wrx '$dir' chown '$user' '$dir' fi done See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/cat /etc/passwd | /usr/bin/egrep -v '^(root|halt|sync|shutdown)' | /usr/bin/awk -F: '($7 != "/sbin/nologin" && $7 != "/bin/false") { print $1 " " $3 " " $6 }'| while read user uid dir; do if [ ! -d "$dir" ]; then /usr/bin/echo "The home directory ($dir) of user $user does not exist."; fi; done | /usr/bin/awk '{print} END {if (NR == 0) print "pass"'}' returned :
pass lab-preventaThe command '/usr/bin/cat /etc/passwd | /usr/bin/egrep -v '^(root|halt|sync|shutdown)' | /usr/bin/awk -F: '($7 != "/sbin/nologin" && $7 != "/bin/false") { print $1 " " $3 " " $6 }'| while read user uid dir; do if [ ! -d "$dir" ]; then /usr/bin/echo "The home directory ($dir) of user $user does not exist."; fi; done | /usr/bin/awk '{print} END {if (NR == 0) print "pass"'}' returned :
pass 6.2.12 Ensure users own their home directoriesInfoThe user home directory is space defined for the particular user to set local environment variables and to store personal files.Rationale: Since the user is accountable for files stored in the user home directory, the user must be the owner of the directory. SolutionChange the ownership of any home directories that are not owned by the defined user to the correct user.The following script will create missing home directories, set the owner, and set the permissions for interactive users' home directories: #!/bin/bash awk -F: '($1!~/(halt|sync|shutdown|nfsnobody)/ && $7!~/^(/usr)?/sbin/nologin(/)?$/ && $7!~/(/usr)?/bin/false(/)?$/) { print $1 ' ' $6 }' /etc/passwd | while read -r user dir; do if [ ! -d '$dir' ]; then echo 'User: '$user' home directory: '$dir' does not exist, creating home directory' mkdir '$dir' chmod g-w,o-rwx '$dir' chown '$user' '$dir' else owner=$(stat -L -c '%U' '$dir') if [ '$owner' != '$user' ]; then chmod g-w,o-rwx '$dir' chown '$user' '$dir' fi fi done See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaNo issues found.
lab-preventaNo issues found.
6.2.13 Ensure users' home directories permissions are 750 or more restrictiveInfoWhile the system administrator can establish secure permissions for users' home directories, the users can easily override these.Rationale: Group or world-writable user home directories may enable malicious users to steal or modify other users' data or to gain another user's system privileges. SolutionMaking global modifications to user home directories without alerting the user community can result in unexpected outages and unhappy users. Therefore, it is recommended that a monitoring policy be established to report user file permissions and determine the action to be taken in accordance with site policy.The following script can be used to remove permissions is excess of 750 from users' home directories: #!/bin/bash awk -F: '($1!~/(halt|sync|shutdown|nfsnobody)/ && $7!~/^(/usr)?/sbin/nologin(/)?$/ && $7!~/(/usr)?/bin/false(/)?$/) {print $6}' /etc/passwd | while read -r dir; do if [ -d '$dir' ]; then dirperm=$(stat -L -c '%A' '$dir') if [ '$(echo '$dirperm' | cut -c6)' != '-' ] || [ '$(echo '$dirperm' | cut -c8)' != '-' ] || [ '$(echo '$dirperm' | cut -c9)' != '-' ] || [ '$(echo '$dirperm' | cut -c10)' != '-' ]; then chmod g-w,o-rwx '$dir' fi fi done See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaNo issues found.
lab-preventaNo issues found.
6.2.14 Ensure users' dot files are not group or world writableInfoWhile the system administrator can establish secure permissions for users' 'dot' files, the users can easily override these.Rationale: Group or world-writable user configuration files may enable malicious users to steal or modify other users' data or to gain another user's system privileges. SolutionMaking global modifications to users' files without alerting the user community can result in unexpected outages and unhappy users. Therefore, it is recommended that a monitoring policy be established to report user dot file permissions and determine the action to be taken in accordance with site policy.The following script will remove excessive permissions on dot files within interactive users' home directories. #!/bin/bash awk -F: '($1!~/(halt|sync|shutdown|nfsnobody)/ && $7!~/^(/usr)?/sbin/nologin(/)?$/ && $7!~/(/usr)?/bin/false(/)?$/) { print $6 }' /etc/passwd | while read -r dir; do if [ -d '$dir' ]; then for file in '$dir'/.*; do if [ ! -h '$file' ] && [ -f '$file' ]; then fileperm=$(stat -L -c '%A' '$file') if [ '$(echo '$fileperm' | cut -c6)' != '-' ] || [ '$(echo '$fileperm' | cut -c9)' != '-' ]; then chmod go-w '$file' fi fi done fi done See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command returned :
All dot files have proper permissions lab-preventaThe command returned :
All dot files have proper permissions 6.2.15 Ensure no users have .forward filesInfoThe .forward file specifies an email address to forward the user's mail to.Rationale: Use of the .forward file poses a security risk in that sensitive data may be inadvertently transferred outside the organization. The .forward file also poses a risk as it can be used to execute commands that may perform unintended actions. SolutionMaking global modifications to users' files without alerting the user community can result in unexpected outages and unhappy users. Therefore, it is recommended that a monitoring policy be established to report user .forward files and determine the action to be taken in accordance with site policy.The following script will remove .forward files from interactive users' home directories #!/bin/bash awk -F: '($1!~/(root|halt|sync|shutdown|nfsnobody)/ && $7!~/^(/usr)?/sbin/nologin(/)?$/ && $7!~/(/usr)?/bin/false(/)?$/) { print $6 }' /etc/passwd | while read -r dir; do if [ -d '$dir' ]; then file='$dir/.forward' [ ! -h '$file' ] && [ -f '$file' ] && rm -r '$file' fi done See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command returned :
No .forward files found lab-preventaThe command returned :
No .forward files found 6.2.16 Ensure no users have .netrc filesInfoThe .netrc file contains data for logging into a remote host for file transfers via FTP.While the system administrator can establish secure permissions for users' .netrc files, the users can easily override these. Rationale: The .netrc file presents a significant security risk since it stores passwords in unencrypted form. Even if FTP is disabled, user accounts may have brought over .netrc files from other systems which could pose a risk to those systems. If a .netrc file is required, and follows local site policy, it should have permissions of 600 or more restrictive. SolutionMaking global modifications to users' files without alerting the user community can result in unexpected outages and unhappy users. Therefore, it is recommended that a monitoring policy be established to report user .netrc files and determine the action to be taken in accordance with site policy.The following script will remove .netrc files from interactive users' home directories #!/bin/bash awk -F: '($1!~/(halt|sync|shutdown|nfsnobody)/ && $7!~/^(/usr)?/sbin/nologin(/)?$/ && $7!~/(/usr)?/bin/false(/)?$/) { print $6 }' /etc/passwd | while read -r dir; do if [ -d '$dir' ]; then file='$dir/.netrc' [ ! -h '$file' ] && [ -f '$file' ] && rm -f '$file' fi done Additional Information: While the complete removal of .netrc files is recommended, if any are required on the system secure permissions must be applied. See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command returned :
No .netrc files found lab-preventaThe command returned :
No .netrc files found 6.2.17 Ensure no users have .rhosts filesInfoWhile no .rhosts files are shipped by default, users can easily create them.Rationale: This action is only meaningful if .rhosts support is permitted in the file /etc/pam.conf . Even though the .rhosts files are ineffective if support is disabled in /etc/pam.conf , they may have been brought over from other systems and could contain information useful to an attacker for those other systems. SolutionMaking global modifications to users' files without alerting the user community can result in unexpected outages and unhappy users. Therefore, it is recommended that a monitoring policy be established to report user .rhosts files and determine the action to be taken in accordance with site policy.The following script will remove .rhosts files from interactive users' home directories #!/bin/bash awk -F: '($1!~/(root|halt|sync|shutdown|nfsnobody)/ && $7!~/^(/usr)?/sbin/nologin(/)?$/ && $7!~/(/usr)?/bin/false(/)?$/) { print $6 }' /etc/passwd | while read -r dir; do if [ -d '$dir' ]; then file='$dir/.rhosts' [ ! -h '$file' ] && [ -f '$file' ] && rm -r '$file' fi done See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command returned :
No .rhosts files found lab-preventaThe command returned :
No .rhosts files found 6.2.2 Ensure /etc/shadow password fields are not emptyInfoAn account with an empty password field means that anybody may log in as that user without providing a password.Rationale: All accounts must have passwords or be locked to prevent the account from being used by an unauthorized user. SolutionIf any accounts in the /etc/shadow file do not have a password, run the following command to lock the account until it can be determined why it does not have a password:# passwd -l <username> Also, check to see if the account is logged in and investigate what it is being used for to determine if it needs to be forced off. See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/bin/awk -F: '($2 == "" ) { print $1 " does not have a password "}' /etc/shadow | /bin/awk '{print} END {if (NR == 0) print "pass"; else print "fail"}'' returned :
pass lab-preventaThe command '/bin/awk -F: '($2 == "" ) { print $1 " does not have a password "}' /etc/shadow | /bin/awk '{print} END {if (NR == 0) print "pass"; else print "fail"}'' returned :
pass 6.2.3 Ensure all groups in /etc/passwd exist in /etc/groupInfoOver time, system administration errors and changes can lead to groups being defined in /etc/passwd but not in /etc/group .Rationale: Groups defined in the /etc/passwd file but not in the /etc/group file pose a threat to system security since group permissions are not properly managed. SolutionAnalyze the output of the Audit step above and perform the appropriate action to correct any discrepancies found.See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaNo issues found.
lab-preventaNo issues found.
6.2.4 Ensure shadow group is empty - /etc/groupInfoThe shadow group allows system programs which require access the ability to read the /etc/shadow file. No users should be assigned to the shadow group.Rationale: Any users assigned to the shadow group would be granted read access to the /etc/shadow file. If attackers can gain read access to the /etc/shadow file, they can easily run a password cracking program against the hashed passwords to break them. Other security information that is stored in the /etc/shadow file (such as expiration) could also be useful to subvert additional user accounts. SolutionRun the following command to remove all users from the shadow group# sed -ri 's/(^shadow:[^:]*:[^:]*:)([^:]+$)/1/' /etc/group Change the primary group of any users with shadow as their primary group. # usermod -g <primary group> <user> See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/grep ^shadow:[^:]*:[^:]*:[^:]+ /etc/group | /usr/bin/awk '{print} END {if (NR == 0) print "none"}'' returned :
none lab-preventaThe command '/usr/bin/grep ^shadow:[^:]*:[^:]*:[^:]+ /etc/group | /usr/bin/awk '{print} END {if (NR == 0) print "none"}'' returned :
none 6.2.4 Ensure shadow group is empty - /etc/passwdInfoThe shadow group allows system programs which require access the ability to read the /etc/shadow file. No users should be assigned to the shadow group.Rationale: Any users assigned to the shadow group would be granted read access to the /etc/shadow file. If attackers can gain read access to the /etc/shadow file, they can easily run a password cracking program against the hashed passwords to break them. Other security information that is stored in the /etc/shadow file (such as expiration) could also be useful to subvert additional user accounts. SolutionRun the following command to remove all users from the shadow group# sed -ri 's/(^shadow:[^:]*:[^:]*:)([^:]+$)/1/' /etc/group Change the primary group of any users with shadow as their primary group. # usermod -g <primary group> <user> See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/awk -F: '($4 == "<shadow-gid>") { print }' /etc/passwd | /usr/bin/awk '{print} END {if (NR == 0) print "none"}'' returned :
none lab-preventaThe command '/usr/bin/awk -F: '($4 == "<shadow-gid>") { print }' /etc/passwd | /usr/bin/awk '{print} END {if (NR == 0) print "none"}'' returned :
none 6.2.5 Ensure no duplicate user names existInfoAlthough the useradd program will not let you create a duplicate user name, it is possible for an administrator to manually edit the /etc/passwd file and change the user name.Rationale: If a user is assigned a duplicate user name, it will create and have access to files with the first UID for that username in /etc/passwd . For example, if 'test4' has a UID of 1000 and a subsequent 'test4' entry has a UID of 2000, logging in as 'test4' will use UID 1000. Effectively, the UID is shared, which is a security problem. SolutionBased on the results of the audit script, establish unique user names for the users. File ownerships will automatically reflect the change as long as the users have unique UIDs.See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaNo issues found.
lab-preventaNo issues found.
6.2.6 Ensure no duplicate group names existInfoAlthough the groupadd program will not let you create a duplicate group name, it is possible for an administrator to manually edit the /etc/group file and change the group name.Rationale: If a group is assigned a duplicate group name, it will create and have access to files with the first GID for that group in /etc/group . Effectively, the GID is shared, which is a security problem. SolutionBased on the results of the audit script, establish unique names for the user groups. File group ownerships will automatically reflect the change as long as the groups have unique GIDs.See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaNo issues found.
lab-preventaNo issues found.
6.2.7 Ensure no duplicate UIDs existInfoAlthough the useradd program will not let you create a duplicate User ID (UID), it is possible for an administrator to manually edit the /etc/passwd file and change the UID field.Rationale: Users must be assigned unique UIDs for accountability and to ensure appropriate access protections. SolutionBased on the results of the audit script, establish unique UIDs and review all files owned by the shared UIDs to determine which UID they are supposed to belong to.See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaNo duplicate User IDs detected
lab-preventaNo duplicate User IDs detected
6.2.8 Ensure no duplicate GIDs existInfoAlthough the groupadd program will not let you create a duplicate Group ID (GID), it is possible for an administrator to manually edit the /etc/group file and change the GID field.Note: You can also use the grpck command to check for other inconsistencies in the /etc/group file. Rationale: User groups must be assigned unique GIDs for accountability and to ensure appropriate access protections. SolutionBased on the results of the audit script, establish unique GIDs and review all files owned by the shared GID to determine which group they are supposed to belong to.Additional Information: You can also use the grpck command to check for other inconsistencies in the /etc/group file. See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaNo duplicate Group IDs detected
lab-preventaNo duplicate Group IDs detected
6.2.9 Ensure root is the only UID 0 accountInfoAny account with UID 0 has superuser privileges on the system.Rationale: This access must be limited to only the default root account and only from the system console. Administrative access must be through an unprivileged account using an approved mechanism as noted in Item 5.6 Ensure access to the su command is restricted. SolutionRemove any users other than root with UID 0 or assign them a new UID if appropriate.See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaNo issues found.
lab-preventaNo issues found.
CIS_CentOS_7_v3.1.2_Server_L1.audit from CIS CentOS 7 Benchmark v3.1.2InfoThis audit checks the testable Level 1 guidance in the CIS CentOS 7 Benchmark document.SolutionSee Alsohttps://workbench.cisecurity.org/files/3490Assetslab-preventaCIS_CentOS_7_v3.1.2_Workstation_L1.audit from CIS CentOS 7 Benchmark v3.1.2InfoThis audit checks the testable Level 1 guidance in the CIS CentOS 7 Benchmark document.SolutionSee Alsohttps://workbench.cisecurity.org/files/3490Assetslab-preventaAudits INFO,WARNING,ERROR1.2.2 Ensure package manager repositories are configuredInfoSystems need to have package manager repositories configured to ensure they receive the latest patches and updates.Rationale: If a system's package repositories are misconfigured important patches may not be identified or a rogue repository could introduce compromised software. NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance. SolutionConfigure your package manager repositories according to site policy.See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/yum repolist' returned :
Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: edgeuno-bog2.mm.fcix.net * extras: edgeuno-bog2.mm.fcix.net * updates: edgeuno-bog2.mm.fcix.net repo id repo name status !base/7/x86_64 CentOS-7 - Base 10072 !docker-ce-stable/7/x86_64 Docker CE Stable - x86_64 264 !extras/7/x86_64 CentOS-7 - Extras 518 !updates/7/x86_64 CentOS-7 - Updates 5367 repolist: 16221 lab-preventaThe command '/usr/bin/yum repolist' returned :
Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: edgeuno-bog2.mm.fcix.net * extras: edgeuno-bog2.mm.fcix.net * updates: edgeuno-bog2.mm.fcix.net repo id repo name status base/7/x86_64 CentOS-7 - Base 10072 docker-ce-stable/7/x86_64 Docker CE Stable - x86_64 264 extras/7/x86_64 CentOS-7 - Extras 518 updates/7/x86_64 CentOS-7 - Updates 5367 repolist: 16221 1.7.1 Ensure message of the day is configured properly - banner textInfoThe contents of the /etc/motd file are displayed to users after login and function as a message of the day for authenticated users.Unix-based systems have typically displayed information about the OS release and patch level upon logging in to the system. This information can be useful to developers who are developing software for a particular OS platform. If mingetty(8) supports the following options, they display operating system information: m - machine architecture r - operating system release s - operating system name v - operating system version Rationale: Warning messages inform users who are attempting to login to the system of their legal status regarding the system and must include the name of the organization that owns the system and any monitoring policies that are in place. Displaying OS and patch level information in login banners also has the side effect of providing detailed system information to attackers attempting to target specific exploits of a system. Authorized users can easily get this information by running the ' uname -a ' command once they have logged in. SolutionEdit the /etc/motd file with the appropriate contents according to your site policy, remove any instances of m , r , s , v or references to the OS platform OR If the motd is not used, this file can be removed.Run the following command to remove the motd file: # rm /etc/motd See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa2.4 Ensure nonessential services are removed or maskedInfoA network port is identified by its number, the associated IP address, and the type of the communication protocol such as TCP or UDP.A listening port is a network port on which an application or process listens on, acting as a communication endpoint. Each listening port can be open or closed (filtered) using a firewall. In general terms, an open port is a network port that accepts incoming packets from remote locations. Rationale: Services listening on the system pose a potential risk as an attack vector. These services should be reviewed, and if not required, the service should be stopped, and the package containing the service should be removed. If required packages have a dependency, the service should be stopped and masked to reduce the attack surface of the system. NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance. SolutionRun the following command to remove the package containing the service:# yum remove <package_name> OR If required packages have a dependency: Run the following command to stop and mask the service: # systemctl --now mask <service_name> See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/sbin/lsof -i -P -n | /usr/bin/grep -v '(ESTABLISHED)'' returned :
sh: /usr/sbin/lsof: No such file or directory lab-preventaThe command '/usr/sbin/lsof -i -P -n | /usr/bin/grep -v '(ESTABLISHED)'' returned :
sh: /usr/sbin/lsof: No such file or directory 3.5.1.6 Ensure network interfaces are assigned to appropriate zoneInfofirewall zones define the trust level of network connections or interfaces.Rationale: A network interface not assigned to the appropriate zone can allow unexpected or undesired network traffic to be accepted on the interface. Impact: Changing firewall settings while connected over network can result in being locked out of the system. NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance. SolutionRun the following command to assign an interface to the approprate zone.# firewall-cmd --zone=<Zone NAME> --change-interface=<INTERFACE NAME> Example: # firewall-cmd --zone=customezone --change-interface=eth0 Default Value: default zone defined in the firewalld configuration See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/nmcli -t connection show | /usr/bin/awk -F: '{if($4){print $4}}' | while read INT; do /usr/bin/firewall-cmd --get-active-zones | /usr/bin/grep -B1 $INT; done' returned :
public interfaces: eth0 docker interfaces: br-a4814e5abd8e docker0 lab-preventaThe command '/usr/bin/nmcli -t connection show | /usr/bin/awk -F: '{if($4){print $4}}' | while read INT; do /usr/bin/firewall-cmd --get-active-zones | /usr/bin/grep -B1 $INT; done' returned :
public interfaces: eth0 docker interfaces: br-a4814e5abd8e docker0 3.5.1.7 Ensure firewalld drops unnecessary services and portsInfoServices and ports can be accepted or explicitly rejected or dropped by a zone.For every zone, you can set a default behavior that handles incoming traffic that is not further specified. Such behavior is defined by setting the target of the zone. There are three options - default, ACCEPT, REJECT, and DROP. ACCEPT - you accept all incoming packets except those disabled by a specific rule. REJECT - you disable all incoming packets except those that you have allowed in specific rules and the source machine is informed about the rejection. DROP - you disable all incoming packets except those that you have allowed in specific rules and no information sent to the source machine. Rationale: To reduce the attack surface of a system, all services and ports should be blocked unless required NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance. SolutionRun the following command to remove an unnecessary service:# firewall-cmd --remove-service=<service> Example: # firewall-cmd --remove-service=cockpit Run the following command to remove an unnecessary port: # firewall-cmd --remove-port=<port-number>/<port-type> Example: # firewall-cmd --remove-port=25/tcp Run the following command to make new settings persistent: # firewall-cmd --runtime-to-permanent See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe command '/usr/bin/firewall-cmd --get-active-zones | /usr/bin/awk '!/:/ {print $1}' | while read ZN; do /usr/bin/firewall-cmd --list-all --zone=$ZN; done' returned :
docker (active) target: ACCEPT icmp-block-inversion: no interfaces: br-a4814e5abd8e docker0 sources: services: ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: public (active) target: default icmp-block-inversion: no interfaces: eth0 sources: services: dhcpv6-client ssh ports: 8834/tcp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: lab-preventaThe command '/usr/bin/firewall-cmd --get-active-zones | /usr/bin/awk '!/:/ {print $1}' | while read ZN; do /usr/bin/firewall-cmd --list-all --zone=$ZN; done' returned :
docker (active) target: ACCEPT icmp-block-inversion: no interfaces: br-a4814e5abd8e docker0 sources: services: ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: public (active) target: default icmp-block-inversion: no interfaces: eth0 sources: services: dhcpv6-client ssh ports: 8834/tcp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: 4.2.4 Ensure logrotate is configuredInfoThe system includes the capability of rotating log files regularly to avoid filling up the system with logs or making the logs unmanageably large. The file /etc/logrotate.d/syslog is the configuration file used to rotate log files created by syslog or rsyslog.Note: If no maxage setting is set for logrotate a situation can occur where logrotate is interrupted and fails to delete rotated logfiles. It is recommended to set this to a value greater than the longest any log file should exist on your system to ensure that any such logfile is removed but standard rotation settings are not overridden. Rationale: By keeping the log files smaller and more manageable, a system administrator can easily archive these files to another system and spend less time looking through inordinately large log files. NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance. SolutionEdit /etc/logrotate.conf and /etc/logrotate.d/* to ensure logs are rotated according to site policy.See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventalab-preventa6.1.13 Audit SUID executablesInfoThe owner of a file can set the file's permissions to run with the owner's or group's permissions, even if the user running the program is not the owner or a member of the group. The most common reason for a SUID program is to enable users to perform functions (such as changing their password) that require root privileges.Rationale: There are valid reasons for SUID programs, but it is important to identify and review such programs to ensure they are legitimate. NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance. SolutionEnsure that no rogue SUID programs have been introduced into the system. Review the files returned by the action in the Audit section and confirm the integrity of these binaries.See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventa The following 34 files are SUID:
/var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/bin/mount owner: root, group: root, permissions: 4755 /var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/bin/su owner: root, group: root, permissions: 4755 /var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/bin/umount owner: root, group: root, permissions: 4755 /var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/usr/bin/chfn owner: root, group: root, permissions: 4755 /var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/usr/bin/chsh owner: root, group: root, permissions: 4755 /var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/usr/bin/gpasswd owner: root, group: root, permissions: 4755 /var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/usr/bin/newgrp owner: root, group: root, permissions: 4755 /var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/usr/bin/passwd owner: root, group: root, permissions: 4755 /var/lib/docker/overlay2/36cd1e421130f471976b036f92835ed3bce81e77c5255c721740ff498141d4a6/diff/bin/mount owner: root, group: root, permissions: 4755 /var/lib/docker/overlay2/36cd1e421130f471976b036f92835ed3bce81e77c5255c721740ff498141d4a6/diff/bin/su owner: root, group: root, permissions: 4755 /var/lib/docker/overlay2/36cd1e421130f471976b036f92835ed3bce81e77c5255c721740ff498141d4a6/diff/bin/umount owner: root, group: root, permissions: 4755 /var/lib/docker/overlay2/36cd1e421130f471976b036f92835ed3bce81e77c5255c721740ff498141d4a6/diff/usr/bin/chfn owner: root, group: root, permissions: 4755 [...] lab-preventa The following 34 files are SUID:
/var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/bin/mount owner: root, group: root, permissions: 4755 /var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/bin/su owner: root, group: root, permissions: 4755 /var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/bin/umount owner: root, group: root, permissions: 4755 /var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/usr/bin/chfn owner: root, group: root, permissions: 4755 /var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/usr/bin/chsh owner: root, group: root, permissions: 4755 /var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/usr/bin/gpasswd owner: root, group: root, permissions: 4755 /var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/usr/bin/newgrp owner: root, group: root, permissions: 4755 /var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/usr/bin/passwd owner: root, group: root, permissions: 4755 /var/lib/docker/overlay2/36cd1e421130f471976b036f92835ed3bce81e77c5255c721740ff498141d4a6/diff/bin/mount owner: root, group: root, permissions: 4755 /var/lib/docker/overlay2/36cd1e421130f471976b036f92835ed3bce81e77c5255c721740ff498141d4a6/diff/bin/su owner: root, group: root, permissions: 4755 /var/lib/docker/overlay2/36cd1e421130f471976b036f92835ed3bce81e77c5255c721740ff498141d4a6/diff/bin/umount owner: root, group: root, permissions: 4755 /var/lib/docker/overlay2/36cd1e421130f471976b036f92835ed3bce81e77c5255c721740ff498141d4a6/diff/usr/bin/chfn owner: root, group: root, permissions: 4755 [...] 6.1.14 Audit SGID executablesInfoThe owner of a file can set the file's permissions to run with the owner's or group's permissions, even if the user running the program is not the owner or a member of the group. The most common reason for a SGID program is to enable users to perform functions (such as changing their password) that require root privileges.Rationale: There are valid reasons for SGID programs, but it is important to identify and review such programs to ensure they are legitimate. Review the files returned by the action in the audit section and check to see if system binaries have a different md5 checksum than what from the package. This is an indication that the binary may have been replaced. NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance. SolutionEnsure that no rogue SGID programs have been introduced into the system. Review the files returned by the action in the Audit section and confirm the integrity of these binaries.See Alsohttps://workbench.cisecurity.org/files/3490References
Assetslab-preventaThe following 16 files are SGID:
/var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/sbin/unix_chkpwd owner: root, group: 42, permissions: 2755 /var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/usr/bin/chage owner: root, group: 42, permissions: 2755 /var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/usr/bin/expiry owner: root, group: 42, permissions: 2755 /var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/usr/bin/wall owner: root, group: tty, permissions: 2755 /var/lib/docker/overlay2/36cd1e421130f471976b036f92835ed3bce81e77c5255c721740ff498141d4a6/diff/sbin/unix_chkpwd owner: root, group: 42, permissions: 2755 /var/lib/docker/overlay2/36cd1e421130f471976b036f92835ed3bce81e77c5255c721740ff498141d4a6/diff/usr/bin/chage owner: root, group: 42, permissions: 2755 /var/lib/docker/overlay2/36cd1e421130f471976b036f92835ed3bce81e77c5255c721740ff498141d4a6/diff/usr/bin/expiry owner: root, group: 42, permissions: 2755 /var/lib/docker/overlay2/36cd1e421130f471976b036f92835ed3bce81e77c5255c721740ff498141d4a6/diff/usr/bin/wall owner: root, group: tty, permissions: 2755 /usr/bin/wall owner: root, group: tty, permissions: 2555 /usr/bin/write owner: root, group: tty, permissions: 2755 /usr/bin/ssh-agent owner: root, group: nobody, permissions: 2111 /usr/sbin/netreport owner: root, group: root, permissions: 2755 /usr/sbin/postdrop owner: root, group: postdrop, permissions: 2755 /usr/sbin/postqueue owner: root, group: postdrop, permissions: 2755 /usr/libexec/utempter/utempter owner: root, group: utmp, permissions: 2711 /usr/libexec/openssh/ssh-keysign owner: root, group: ssh_keys, permissions: 2111 lab-preventaThe following 16 files are SGID:
/var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/sbin/unix_chkpwd owner: root, group: 42, permissions: 2755 /var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/usr/bin/chage owner: root, group: 42, permissions: 2755 /var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/usr/bin/expiry owner: root, group: 42, permissions: 2755 /var/lib/docker/overlay2/1f9f917b5bb0ca71c1aa061c61b7fcb4e3788cdf3a295b7370b00732525ee616/diff/usr/bin/wall owner: root, group: tty, permissions: 2755 /var/lib/docker/overlay2/36cd1e421130f471976b036f92835ed3bce81e77c5255c721740ff498141d4a6/diff/sbin/unix_chkpwd owner: root, group: 42, permissions: 2755 /var/lib/docker/overlay2/36cd1e421130f471976b036f92835ed3bce81e77c5255c721740ff498141d4a6/diff/usr/bin/chage owner: root, group: 42, permissions: 2755 /var/lib/docker/overlay2/36cd1e421130f471976b036f92835ed3bce81e77c5255c721740ff498141d4a6/diff/usr/bin/expiry owner: root, group: 42, permissions: 2755 /var/lib/docker/overlay2/36cd1e421130f471976b036f92835ed3bce81e77c5255c721740ff498141d4a6/diff/usr/bin/wall owner: root, group: tty, permissions: 2755 /usr/bin/wall owner: root, group: tty, permissions: 2555 /usr/bin/write owner: root, group: tty, permissions: 2755 /usr/bin/ssh-agent owner: root, group: nobody, permissions: 2111 /usr/sbin/netreport owner: root, group: root, permissions: 2755 /usr/sbin/postdrop owner: root, group: postdrop, permissions: 2755 /usr/sbin/postqueue owner: root, group: postdrop, permissions: 2755 /usr/libexec/utempter/utempter owner: root, group: utmp, permissions: 2711 /usr/libexec/openssh/ssh-keysign owner: root, group: ssh_keys, permissions: 2111 |
